I recommend that if you want answers from both sides of the issue of COPS/PR versus SNMPCONF, you should send your mail to both the RAP WG and the SNMPCONF WG. And you should be prepared for very biased, and often inflammatory and misleading, information from both sides.
There are a number of differences between these two approaches, and neither is a clear winner. I don't find either approach compelling, but I need to recuse myself, since I have been a co-chair of the SNMPCONF WG in the past, and have done work on the COPS/PR specifications. You'll need decide for yourself which is best. I'll give you an overview of things to look for when doing your analysis, and I'll try to be neutral.
I have two sections. One compares their provisioning ability; the second deals with security issues. You'll need to decide what's important to you and your customers.
Advantages: Designed specifically for provisioning with all the benefits of a protocol designed for the purpose at hand. Event-driven. Object-oriented. Includes explicit provisions for fail-over, role-combinations, and other provisioning-related issues. Able to provision SNMP MIBs, taking advantage of 10,000+ managed objects. Currently depends on SNMP protocol for monitoring, which is widely deployed.
Disadvantages: It is a new protocol not supported on most existing hardware; no hard data about how robust or useful it is as a protocol. The PIB approach is a new mechanism and there is no hard data about how robust or useful it is for expressing policies. The integration between COPS/PR and SNMP has not been fully specified, so applications will need to provide much of the integration "outside" the two protocols. Since it builds upon SNMP data modeling and depends on SNMP monitoring, it suffers all the disadvantages of SNMP when doing data modeling and monitoring.
Advantages: Uses existing SNMP protocol and architecture, with twelve years as a widely-deployed, robust and useful protocol standard for monitoring; lack of security in SNMPv1 has severely limited its use for provisioning. SNMP protocol can be used in a polling-driven or event-driven approach (typically it has been polling-based due to the unreliability of SNMPv1/UDP traps). Able to provision SNMP MIBs, taking advantage of 10,000+ managed objects. Uses SNMP both for provisioning and monitoring, so data is fairly easily correlated.
Disadvantages: Depends on an administrator developing policies using a scripting language that is the amalgum of multiple existing languages. This new programming language is not supported on existing devices, and has no hard data about how robust or useful it is for expressing policies. Since it builds upon SNMP data modeling and depends on SNMP for provisioning and monitoring, it suffers all the disadvantages of SNMP when doing data modeling and provisioning or monitoring.
There are differences in security:
SNMPCONF ties into SNMPv3 security, which is not widely deployed, but which addresses user-based authentication and administrator configurable authorization. Encryption provides a tunnel between the manager application and the agent. The integration of the division of responsibility between SNMPCONF policies and SNMPv3 access control has not been clearly defined, although the same administrators are likely to write the policies and configure the access control.
COPS/PR security depends on IPSec, which uses host-based authentication. IPSec encryption typically provides a tunnel between the host running the manager application and the device running the agent. The host-based approach may or may not be adequate depending on the division of responsibilities in an organization. Authorization to manipulate provisioning data depends on clearly separated responsibilities of clients that may be produced by different vendors; different vendors may divide responsibilities differently making it more difficult to write vendor-neutral policies. The integration of the division of responsibility between COPS/PR policies and SNMPv3 access control has not been clearly defined; COPS/PR division of responsibility is largely client-vendor-dependent, while SNMPv3 access control is configured by the network administrator.
I'm sure both sides will find fault with my analysis. You'll need to do your own analysis to determine how they compare for the purpose to which you want to put them. Hopefully my suggestions will give you some idea of the things to look at more closely.
co-chair, IETF SNMPv3 WG
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:firstname.lastname@example.org]
> Sent: Monday, February 25, 2002 1:49 PM
> To: Durham, David; 'Tricha Anjali'; email@example.com
> Cc: Ian F. Akyildiz
> Subject: RE: COPS vs. SNMP
> David, I am not sure what you are trying to tell people?
> The SNMP CERT advisories have NOT talked about a flaw
> in the SNMP Protocol at all. They have talked about implementation
> bugs. Further, it seems that most implementation bugs have been
> in the area of not properly decoding BER encoded SNMP packets.
> Since the COPS-PR with PIB approach also uses BER encoding for
> sending the configuration/policy information, I would suspect
> that COPS-PR implementations have the same potential risks!!!
> > -----Original Message-----
> > From: Durham, David [mailto:firstname.lastname@example.org]
> > Sent: Monday, February 25, 2002 7:32 PM
> > To: 'Tricha Anjali'; email@example.com
> > Cc: Ian F. Akyildiz
> > Subject: RE: COPS vs. SNMP
> > I'm interested in what the industry adoption of SNMPConf is/will be.
> > Particularly given that CERT is already advising that
> > administrators TURN
> > SNMP OFF! Eg. SNMP is currently undergoing a maelstrom of
> > CERT advisories
> > and other bad press due to its
> > troubling susceptibilities. Now just imagine allowing people
> > to actually
> > download viruses and worms via SNMPConf PM MIB's Scripts.
> > -Dave
> > http://www.internetwk.com/story/INW20020213S0002
> > > -----Original Message-----
> > > From: Tricha Anjali [mailto:firstname.lastname@example.org]
> > > Sent: Monday, February 25, 2002 9:38 AM
> > > To: email@example.com
> > > Cc: Ian F. Akyildiz
> > > Subject: COPS vs. SNMP
> > >
> > >
> > >
> > > Hello,
> > >
> > > We have been following the IETF activities concerning the
> > > ongoing work in
> > > the fields of SNMP and COPS. It seems that at the meeting in
> > > March 2000 in
> > > Adelaide, the snmpconf working group was formed for issues
> > > dealing with
> > > policy-based network management after the BOF about network
> > > management in
> > > Dec 1999. However, now the group seems to have accomplished
> > > its charter
> > > and finished. Does this mean that the discussion has been
> > >
> > > We would like to know if the resource reservation in a
> > > network can/should
> > > be achieved via COPS? If yes, how is it advantageous over SNMP?
> > >
> > > Any help will be appreciated!
> > >
> > > Thanks in advance,
> > >
> > > Tricha
> > >
> > > -------------------------------
> > > Tricha Anjali
> > > Broadband & Wireless Networking Lab
> > > School of Electrical and Computer Engineering
> > > Georgia Institute of Technology
> > > http://users.ece.gatech.edu/~tricha/
> > >
> > >
> > >
> > >