[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ipcdn] draft-ietf-ipcdn-device-mibv2-01.txt



Inline

> -----Original Message-----
> From: RJ Atkinson [mailto:rja@extremenetworks.com]
> Sent: Monday, April 22, 2002 4:24 PM
> To: C. M. Heard
> Cc: mibs@ops.ietf.org; ipcdn@ietf.org
> Subject: Re: [ipcdn] draft-ietf-ipcdn-device-mibv2-01.txt
> 
> On Friday, April 19, 2002, at 04:15 , C. M. Heard wrote:
> > This may have been an oversight, but there was a good reason to 
> > emphasize
> > SNMPv1 here -- it was (and still is) an Internet Standard and a
> > recommended protocol, although this will soon change
> 
> I (erroneously ?) thought SNMPv1 was already moved to HISTORIC
> and SNMPv3 to full STANDARD by the IESG.  If IESG has approved,
> then the state has already changed even if the new RFCs haven't
> made it out of the RFC Editor queue.
> 
IESG has approved SNMPv3 as full STANDARD. 
REclassification of SNMPv1 to HISTORIC is awaiting an update
to RFC2570, so that we have some text that explains why this 
is done.

> >  -- while SNMPv2c
> > was never on the standards track (it was experimental) and was never
> > a recommended protocol.
> 
Correct, and my understanding is that SNMPv2c will be made HISTORIC
at same time as SNMPv1 goes HISTORIC. Again this should be explained
in update to 2570.

> 	In practice, many many folks erroneously thought that SNMPv2c
> included cryptographic authentication -- and SNMPv2c is quite widely
> deployed (mainly in order to use SMIv2), so it is a large part of the
> deployed Internet.  On that basis (being a large part of the
> deployed Internet), it needs to be discussed in any Security
> Considerations section regardless of its theoretical IETF state.
> 
I agree that it makes sense to include it.

> > The new SNMPv3 documents will be published soon, and the boilerplate 
> > will all have to be updated then.  The admonition against the insecure 
> > historic protocols might as well be updated to say just don't use them.
> 
> Agree with all of that.
> 
> Ran
> 
> 
Bert