RE: RE: SNMPv3 as MIDCOM protocol: Opinions?

Hi,

Let me respond as an evaluator, as SNMPv3 WG author/co-chair, and as a vendor.

As an evaluator, I did not come into the evaluation process as a proponent of a protocol solution. I entered the process because I was asked by the O&M AD to verify that the document was factually accurate, and I found that there were some factual inaccuracies in the representation of SNMP capabilities. As an evaluator, I care that SNMPv3 is factually represented in this evaluation, but I don't care whether SNMPv3 is chosen as the MIDCOM protocol. 

As an author of SNMPv3, and co-chair of SNMPv3 WG, obviously it is always nice to see one's protocol chosen, so I cannot claim complete impartiality. But I also do not see MIDCOM as ever becoming the "killer app" that will help justify SNMP as a standard protocol. SNMPv3 is already full standard, and SNMP is already well justified for its troubleshooting and monitoring functionality, and arguably for its ability to create and modify configurations of specific functionality. So from this perspective I don't care if SNMPv3 becomes the MIDCOM protocol, and I don't think anybody else in the SNMPv3 community cares a great deal either (I am copying this message to the SNMPv3 WG so anybody who disagrees can respond).

As a vendor, I don't care and I do care. My company produces network equipment that includes firewalls and NAT and IDS functionality, and other features that could benefit from a standard MIDCOM solution. As a vendor, we have no requirement that we use what this WG selects as the MIDCOM protocol, but if the IETF produces a useful standard that does not cost us much to support, we will likely implement the standard. I think it unlikely the market cares which is selected; our customers merely want us to produce something that solves their problems. So for those reasons, I do not care whether SNMPv3 becomes the MIDCOM protocol.

The issue to a vendor is largely one of cost of implementation. We already support SNMPv3 and RADIUS, and we will probably support Diameter as an upgrade to RADIUS if our customers demand it (which so far they do not). Enterasys will probably never support COPS/PR or MEGACO. We already need to deal with the difficulties of balancing security across SNMPv3 and RADIUS (and other protocols), and the problems of balancing security across multiple protocols are significant. Adding an unnecessary protocol to our mix, and addressing the resulting combinatorial security concerns, would be very expensive. We would need to pass on those costs to our customers, who would prefer not to suffer price increases and not to have to learn new protocols to manage their networks when existing protocols could have been used. Therefore, as a vendor, I would much rather see the WG select a protocol that I already need to support and secure anyway, since it would make delivering product easier, and!
 
 would not cause price increases in our products. For those reasons, I would favor SNMPv3 first, and Diameter second.

David Harrington
Network Management Architect
Office of the CTO
Enterasys Networks


> -----Original Message-----
> From: Melinda Shore [mailto:[email protected]]
> Sent: Friday, December 06, 2002 12:13 PM
> To: Juergen Quittek
> Cc: Mary Barnes; 'Durham, David'; '[email protected]'
> Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? 
> 
> 
> > So, you say even if someone showed that XML over HTTPS is 
> the perfect
> > solution, the working group would ignore it?
> 
> No - we absolutely don't value/privilege process over
> technical soundness.  However, we do need to push on ahead
> if we're going to get our work done, and I'm hoping against
> hope that people will start showing greater willingness to
> compromise.  Each of us needs to think hard about what the
> consequences would be for the working group (not our
> employers) if midcom were to select a protocol other than
> the one we individually favor.  Consensus-based decision
> making simply does not work - at all - in the face of
> inflexibility and rigidity on the part of participants.
> 
> Melinda
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom
>