Re: ftp://ftp.cisco.com/fred/rreq-03.txt

David Waitzman <djw@bbn.com> Tue, 03 January 1995 23:52 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10006; 3 Jan 95 18:52 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10002; 3 Jan 95 18:52 EST
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa23562; 3 Jan 95 18:52 EST
Received: from MORPHEUS.BBN.COM by venera.isi.edu (5.65c/5.61+local-20) id <AA01817>; Tue, 3 Jan 1995 15:25:56 -0800
Message-Id: <199501032325.AA01817@venera.isi.edu>
To: rreq@isi.edu
Subject: Re: ftp://ftp.cisco.com/fred/rreq-03.txt
In-Reply-To: Fred's message of Tue, 03 Jan 95 14:36:03 -0800. <v02110107ab2f7901462f@[198.92.24.2]>
Date: Tue, 03 Jan 95 18:24:15 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: David Waitzman <djw@bbn.com>

> >        - SNMPv2 & MIBs         - Add references in the New RFC

> I have put a note to Bob Stewart, copying Marshall Rose and predictable
> others, asking him to either tell me how to change the section or propose
> text. Marshall comments that SNMP V2 should not at this point be reflected
> in this document. I would appreciate further discussion on this point.

SNMPv2 will probably take another year to reach full standard status.
Some of the MIBs RREQ requires are not even at that level yet.  It is
going to take longer than that for the next version of RREQ to come out
(assuming another version follows this one).  Given these, I suggest
that mentioning SNMPv2 is reasonable, but conditionally, as in:

    "When SNMPv2 reaches Full Standard, you MUST implement it.  You MAY
    continue to implement SNMPv1 at that point, but you MUST not allow
    use of SNMPv1 to compromise the security constraints imposed by
    SNMPv2".

Unfortunately, some of the comments and rules in section 8.1.1 do not
apply properly to SNMPv2 and it is probably too early to make v2
specific rules up.  Example: routers need not implement the INFORM
operation.

> Another thought: there is a long list of MIBs in the document, with
> statements of the form:

>         "if you implement feature <foo>, you MUST implement the <foo> MIB,
>          which is RFC <fubar>."

> It occurs to me that this in some sense preempts the IAB Official Protocols
> document, which is likely to be more current in its list. The entire
> discussion and list of MIBs could be changed to:

>         "If an implementation supports a feature for which there is an IETF
>         SNMP MIB, the implementation MUST be SNMP Manageable using that MIB.
>         Implementations SHOULD be based on the version of the MIB which the
>         IAB Official Protocols document dictates is current."

> Am I out of line here? Any arguments as to why I should *not* make that 
> change?

I agree with the change.

-david