Subject: RE: [midcom] SNMPv3

From: "Harrington, David" <[email-masked]>
Date: Fri, 6 Dec 2002 13:35:47 -0500

Hi,

I concur with David's observation. 

SNMPv3 is the protocol submitted for consideration, and it is submitted on the basis that no modifications to the protocol would be required. The EOS PDU structures are an extension to the protocol and are not part of the SNMPv3 submission.

The only changes required for SNMPv3 support would be the development of appropriate MIBs.

dbh

> -----Original Message-----
> From: Durham, David [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 1:04 PM
> To: [email-masked]
> Subject: RE: [midcom] SNMPv3
> 
> 
> I don't think we want to imply that a new (yet non-existent) 
> version of SNMP
> is required to meet the midcom requirements. 
> 
> -Dave
> 
> > -----Original Message-----
> > From: Wes Hardaker [mailto:[email-masked]]
> > 
> > Warning: document far from complete but should be better when it's
> > first published as a WG item.  The PDU structures have changed
> > slightly as well since then, but the concepts are still t same.
> > 
> _______________________________________________
> midcom mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/midcom
> 
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 06 Dec 2002 14:16:23 -0800

>>>>> On Fri, 6 Dec 2002 13:35:47 -0500, "Harrington, David" <[email-masked]> said:

David> SNMPv3 is the protocol submitted for consideration, and it is
David> submitted on the basis that no modifications to the protocol
David> would be required. The EOS PDU structures are an extension to
David> the protocol and are not part of the SNMPv3 submission.

Sorry for confusing people by my post.  I was in no way trying to say
that people should depend on future extensions.  The point was that,
according to the analysis doc, SNMP rates the best (I can't say I
agree or disagree with it, as I haven't read the entire document;  I'm
basing this statement on the summary).  However, the less-than-ideal
aspects of the protocol may be further improved automatically by
future improvements to the protocol, which to me makes it look more
attractive.  Certainly you must make a decision based on what is
available today and not what may happen in the future.  A clear
picture of the future still helps, however.

[Why is it I'm always misunderstood lately.  I think I need to get
more sleep in order to write more clearly stated messages]

-- 
Wes Hardaker
Network Associates Laboratories
_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Pyda Srisuresh <[email-masked]>
Date: Fri, 6 Dec 2002 21:35:37 -0800 (PST)

Folks,

Sorry to chime in somewhat late on this thread.
I suggest we select SNMP as the MIDCOM protocol.
Here is why.

1. I have not heard any firm argument that SNMP does
   not meet the requirement to be a MIDCOM protocol.

   That SNMPv3 is CPU intensive and hence not suitable
   for large scale enterprises/ISPs is an argument against
   security - not against SNMP per se, IMHO. Vendors may
   choose to go with hardware-based security solution (or)
   simply go with SNMPv2.

   That operators don't use SNMP per se is also not a valid 
   argument against SNMP - because operators probably do not
   use any standard configuration protocol. They probably 
   use vendor proprietary CLI, for whatever reason. Most 
   vendors have a CLI for their devices, irrespective of
   whether they support SNMP, COPS etc. on the devices.

   As for the question of MIBs - There in fact is a NATMIB
   draft (draft-ietf-nat-natmib-05.txt) which was posted to
   this WG approximately 2 months ago. Developing a MIB for
   the firewall should be straight forward.

2. Selecting SNMP as the protocol of choice for MIDCOM does 
   not mean we should exclude all other protocols that 
   provide the same funtionality. Middlebox Device vendors 
   and their customers are the ultimate judges of what protocol
   will become the defacto standard. 

   Selection of a protocol by the IETF does not mean that 
   vendors would adapt the protocol right away. If multiple 
   protocol proposals are made along the way, the protocol
   that is most deployed will end up being the defacto 
   standard. Only the protocol(s) with some real-world relevance
   will be embraced by the users.

cheers,
suresh

--- "Harrington, David" <[email-masked]> wrote:
> SNMPv3 is the protocol submitted for consideration, and it is submitted on
> the basis that no modifications to the protocol would be required. The EOS
> PDU structures are an extension to the protocol and are not part of the
> SNMPv3 submission.
> 

=====