Subject: RE: review draft-ietf-snmpv3-coex-v2-02.txt

From: "David Levi" <[email-masked]>
Date: Fri, 21 Feb 2003 12:53:23 -0800

Hi,

Also, we will add the full read-write compliance statement (next-to-last
item in your original comments).

-Dave

> -----Original Message-----
> From: Levi, David [SC100:323:EXCH] 
> Sent: Friday, February 21, 2003 12:38 PM
> To: 'Harrie Hazewinkel'; WG IETF snmpv3
> Cc: David Harrington
> Subject: RE: review draft-ietf-snmpv3-coex-v2-02.txt
> 
> 
> Hi Harrie,
> 
> Please see me comments below . . .
> 
> -Dave
> 
> > -----Original Message-----
> > From: Harrie Hazewinkel [mailto:[email-masked]]
> > Sent: Wednesday, January 08, 2003 5:21 AM
> > To: WG IETF snmpv3
> > Cc: David Harrington
> > Subject: review draft-ietf-snmpv3-coex-v2-02.txt
> > 
> > 
> > Hi,
> > 
> > I have reviewed the draft and here are my comments.
> > I believe there is nothing broken, but some clarifications
> > could be usefull.
> > 
> > See below between pieces of the draft.
> > 
> > 
> > >         Coexistence between Version 1, Version 2, and Version 3
> > >          of the Internet-standard Network Management Framework
> > >                    <draft-ietf-snmpv3-coex-v2-02.txt>
> > 
> > > Abstract
> > >
> > >    The purpose of this document is to describe coexistence between
> > >    version 3 of the Internet-standard Network Management 
> Framework,
> > >    (SNMPv3), version 2 of the Internet-standard Network Management
> > >    Framework (SNMPv2), and the original Internet-standard Network
> > >    Management Framework (SNMPv1).  This document 
> obsoletes RFC 2576
> > >    [21].
> > 
> > Just to be clear. It basically speaks about coexistance between
> > SNMPv1 - SNMPv2, SNMPv1 - SNMPv3, SNMPv2 - SNMPv3. All versions
> > against the other versions. right?
> > 
> > I am asking, since
> > -  for instance, section 1.4 looks like v1 and v2 only (See 
> > there also).
> > -  the document also describes coexistance between SMIv1 and SMIv2
> >        where SMIv2 is a seperate standard.
> >        Is that therefore needed in this document?
> >        Is SMIv1 and SMIv2 not usefull if that will be added in the 
> > abstract?
> 
> 
> I wasn't sure what exactly you were asking us to change here. 
>  It sounded
> like you were suggesting that the parts of the document 
> regarding converting
> from SMIv1 to SMIv2 be removed and put in a different 
> document.  Can you
> clarify this?
> 
> 
> > 
> > >    Table Of Contents
> > [snip]
> > >    B. Changes From RFC1908 
> > ........................................   55
> > 
> > What about the changes since RFC2576?
> > Mentioned already by, "C. M. Heard" <[email-masked]>
> 
> 
> There will be an updated change log in the upcoming I-D.
> 
> 
> > > 1.4.  SNMPv1 and SNMPv2 Access to MIB Data
> > 
> > Correct me if I am wrong, but this is related to the SNMP-PDU
> > and the SNMP-PDU is not different between SNMPv3 and SNMPv2.
> > For MIB access the difference between SNMPv3 and SNMPv2 is nihil,
> > but that is maybe worthwhile mentioning. Also since a big part of
> > the document uses this.
> 
> 
> Added text to clarify this at the end of section 1.4.
> 
> 
> > 
> > >    SNMPv1 access to MIB data may generate SNMPv1 
> > error-status values,
> > >    will never generate exception codes nor use the 
> > Counter64 data type,
> > >    and will provide SNMPv1 format parameters for generating
> > >    notifications.  Note also that SNMPv1 access to MIB data will
> > >    actually never generate a readOnly error (a noSuchName 
> > error would
> > >    always occur in the situation where one would expect a readOnly
> > >    error).
> > >
> > >    SNMPv2 access to MIB data may generate SNMPv2 
> > error-status values,
> > >    may generate exception codes, may use the Counter64 data 
> > type, and
> > >    will provide SNMPv2 format parameters for generating 
> > notifications.
> > >    Note that SNMPv2 access to MIB data will never 
> generate readOnly,
> > >    noSuchName, or badValue errors.
> > 
> > The above two paragraphs make it look like the 'readOnly' 
> > error exists,
> > but may never be used. Maybe it maybe used for SNMPv3.
> 
> 
> That's right, it exists, but is never used.
> 
> 
> > This section 1.4 seems also the be hanging between section 2 and 3.
> 
> 
> Not sure what you mean here, is there something you thought 
> should change?
> 
> 
> > Also later section 4.3 discusses the mapping between SNMPv1 
> > and SNMPv2,
> > but there is also SNMPv3 equal to SNMPv2. Somehow, I get the feeling
> > this is more SMIv1 and SMIv2 access to the MIB.
> 
> 
> Section 4.3 is related to protocol operations, which are defined in
> SNMPv1 and SNMPv2.  Not sure why you thought this was related to SMIv1
> and SMIv2.  Again, was there something you thought should be 
> changed here?
> 
> 
> > > 2.  SMI and Management Information Mappings
> > >
> > > 2.1.  MIB Modules
> > >
> > >    MIB modules defined using the SMIv1 may continue to be 
> used with
> > >    protocol versions which use SNMPv2 PDUs.  However, for the MIB
> >                                                              ^^^^^^^
> > suggested change into 'the SMIv1 MIB', since this section is
> > SMIv1 to SMIv2 translation. (This could be used in more 
> > places later on.)
> 
> 
> Changed 'for the MIB' to 'for SMIv1 MIB'
> 
> 
> > 
> > >    modules to conform to the SMIv2, the following changes 
> > SHALL be made:
> > >
> > > 2.1.1.  Object Definitions
> > >
> > >    In general, conversion of a MIB module does not require the
> > >    deprecation of the objects contained therein.  If the 
> > definition of
> > >    an object is truly inadequate for its intended purpose, 
> > the object
> > >    SHALL be deprecated or obsoleted, otherwise deprecation is not
> > >    required.
> > 
> > I am just curious about the text "If the definition of
> >     an object is truly inadequate for its intended purpose".
> > which does not make it look like a conversion from SMIv1 to SMIv2
> > or vice versa. That is more a design/experience issue.
> 
> 
> This text is just to clarify that converting a MIB from SMIv1 to SMIv2
> does not mean you must deprecate objects, unless there there is some
> other good reason to deprecate them.
> 
> 
> > > 3.  Translating Notifications Parameters
> > >
> > >    This section describes how parameters used for generating
> > >    notifications are translated between the format used for SNMPv1
> > >    notification protocol operations and the format used for SNMPv2
> > >    notification protocol operations.  The parameters used 
> > to generate a
> > >    notification are called 'notification parameters.'  
> The format of
> > >    parameters used for SNMPv1 notification protocol operations is
> > >    refered to in this document as 'SNMPv1 notification 
> > parameters.'  The
> > >    format of parameters used for SNMPv2 notification 
> > protocol operations
> > >    is refered to in this document as 'SNMPv2 notification 
> > parameters.'
> > 
> > What about SNMPv3 'notification parameters'??
> > I guess, this is similar to my comment earlier in section 1.4.
> 
> 
> Since 'notification parameters' are determined by the version 
> of protocol
> operations, there are only SNMPv1 and SNMPv2 'notification 
> parameters.'
> I don't think there's anything we need to change here.
> 
> 
> > > 4.1.1.  Command Generator
> > >
> > >    A command generator must select an appropriate message 
> > version when
> > >    sending requests to another entity.  One way to achieve 
> > this is to
> > >    consult a local database to select the appropriate 
> > message version.
> > >
> > >    In addition, a command generator MUST 'downgrade' 
> > GetBulk requests to
> > >    GetNext requests when selecting SNMPv1 as the message 
> > version for an
> > >    outgoing request.  This is done by simply changing the 
> > operation type
> > >    to GetNext, ignoring any non-repeaters and 
> > max-repetitions values,
> > >    and setting error-status and error-index to zero.
> > 
> > Correct me if I am wrong, but this does not provide the same 
> > functionality
> > from the command generators point of view. Should that be noted??
> 
> 
> This is true, but I think we would be adding too much detail about how
> to implement code if we said anything more here.
> 
> 
> > > 4.1.3.  Notification Originator
> > >
> > >    A notification originator must be able to translate 
> > between SNMPv1
> > >    notification parameters and SNMPv2 notification 
> > parameters in order
> > >    to send a notification using a particular SNMP message 
> > version.  If a
> > >    notification is generated using SNMPv1 notification 
> > parameters, and
> > >    configuration information specifies that notifications 
> > be sent using
> > >    SNMPv2c or SNMPv3, the notification parameters must be 
> > translated to
> > >    SNMPv2 notification parameters.
> > 
> > here I see the first time that SNMPv2c and SNMPv3 are treated 
> > more equal
> > and then maps upon SNMPV2 notification parameters.
> 
> 
> Well, this is the first place it talks about the actual SNMP message
> version being used for sending notifications.  I don't think there's
> anything to change here.
> 
> 
> > > 5.  Message Processing Models and Security Models
> > >
> > >    In order to adapt SNMPv1 (and SNMPv2c) into the SNMP 
> > architecture,
> > >    the following models are defined in this document:
> > >
> > >        -  The SNMPv1 Message Processing Model
> > >
> > >        -  The SNMPv1 Community-Based Security Model
> > >
> > >    The following models are also described in this document:
> > 
> > The above sentence seems redundant if the '(' and ')' earlier
> > are deleted. Why not listing them just four bullets??
> 
> 
> This parentheses are there because we wanted to try to 
> de-emphasize the
> stuff
> about SNMPv2c.  This was discussed long ago (I can't remember whether
> it was at an IETF meeting or an interim meeting).  We've removed the
> sentence
> between the two bullets, though.
> 
>  
> > >        -  The SNMPv2c Message Processing Model
> > >
> > >        -  The SNMPv2c Community-Based Security Model
> > >
> > >           In most respects, the SNMPv1 Message Processing 
> > Model and the
> > >           SNMPv2c Message Processing Model are identical, 
> > and so these
> > >           are not discussed independently in this document. 
> >  Differences
> > >           between the two models are described as required.
> > >
> > >           Similarly, the SNMPv1 Community-Based Security 
> > Model and the
> > >           SNMPv2c Community-Based Security Model are nearly 
> > identical,
> > >           and so are not discussed independently.  
> > Differences between
> > >           these two models are also described as required.
> > 
> > The indent of the last 2 paragraphs make it look like it is 
> only part
> > of SNMPv2C. Not needed in my opinion.
> 
> 
> The indentation was a typo, it has been fixed.
> 
> 
> > > 5.3.  The SNMP Community MIB Module
> > >
> > >       snmpCommunityMIBCompliance MODULE-COMPLIANCE
> > >           STATUS       current
> > >           DESCRIPTION
> > >               "The compliance statement for SNMP engines which
> > >                implement the SNMP-COMMUNITY-MIB."
> > >
> > >           MODULE       -- this module
> > >               MANDATORY-GROUPS { snmpCommunityTableGroup }
> > >
> > >               OBJECT           snmpCommunityName
> > >               MIN-ACCESS       read-only
> > >               DESCRIPTION     "Write access is not required."
> > >
> > >               OBJECT           snmpCommunitySecurityName
> > >               MIN-ACCESS       read-only
> > >               DESCRIPTION     "Write access is not required."
> > >
> > >               OBJECT           snmpCommunityContextEngineID
> > >               MIN-ACCESS       read-only
> > >               DESCRIPTION     "Write access is not required."
> > >
> > >               OBJECT           snmpCommunityContextName
> > >               MIN-ACCESS       read-only
> > >               DESCRIPTION     "Write access is not required."
> > >
> > >               OBJECT           snmpCommunityTransportTag
> > >               MIN-ACCESS       read-only
> > >               DESCRIPTION     "Write access is not required."
> > >
> > >               OBJECT           snmpCommunityStorageType
> > >               MIN-ACCESS       read-only
> > >               DESCRIPTION     "Write access is not required."
> > >
> > >               OBJECT           snmpCommunityStatus
> > >               MIN-ACCESS       read-only
> > >               DESCRIPTION     "Write access is not required."
> > >
> > >           ::= { snmpCommunityMIBCompliances 1 }
> > 
> > I remember a discussion of having full compliance and read-only
> > compliance in some other MIB modules, like DIFFSERV-MIB. (Bert maybe
> > as well, he can as AD provide IESG guidelines, I hope. It was laid
> > down on other working groups after all too and I do not see a reason
> > why telling other WG to do it, while we ourselves don't do it.)
> > That could be usefull, in order to have people implementing
> > it also as read-write in order to be fully compliant.
> > This would mean just adding a full-compliance statement where it
> > is all implemented and with read/write.
> > 
> > >
> > > 9.  References
> > 
> > Should these not be split into normative and informational
> > references.
> 
> 
> Done.
> 
> 
> > 
> > cheers,
> > 
> > Harrie
> > ------------------------------------------------------------------
> > Author of MOD-SNMP, enabling SNMP management of Apache HTTP server
> > 
>

---

From: Harrie Hazewinkel <[email-masked]>
Date: Mon, 24 Feb 2003 11:24:48 +0100

HI,

> > from SMIv1 to SMIv2 be removed and put in a different

I was indeed not that clear, I was also stating more a question. IMO, 
the
abstract could be made more precise.
This document not only handles SNMP protocol version differences,
but also SMI version differences. Not that I want to seperate that.
For SNMPv1 the connection to SMIv1 is clear (those go hand-in-hand), but
SNMPv2 and SNMPv3 both have SMIv2 plus the fact that SMIv2 is a seperate
STD58. Therefore, I believe that if SMIv2 is seperated also the abstract
should mention it unless we have to see some version of SMI as an
integral part of some version of the 'Internet-standard Network
Management Framework'.

> > Not sure what you mean here, is there something you thought

What I think is odd is that it all seperates the SNMP protocol
versions nicely and section 1.4 combines 2 versions of SMI. Therefore, 
it
looks like this section is somewhere between section 2 and 3.

What I would do (believe should be done) is drop this section and make 
it
part of section 2.
> > I don't think there's anything we need to change here.

See "4.1.3.  Notification Originator" below.

> > to implement code if we said anything more here.

Understand.

> > version being used for sending notifications.  I don't think there's

Now I see why SNMPv3 is not always mentioned/repeated again after 
SNMPv2.
The difference is an SNMP message and SNMP PDU simply said. SNMPv3 uses
SNMPv2 PDUs. Altough, that is quit clear to me, but I did not get this
fully while reading the document.
An 'ignorant' reader would be confused by this.

Therefore, I believe it could be a good idea to add a line in section
1.3 explaining that SNMPv3 is not always mentioned/repeated specifically
when it is about/uses the same definitions as SNMPv2.

> 1.3.  SNMPv3
>    SNMPv3 also uses the SNMPv2 definitions of RFCs 1905 through 1907 
> and
>    the SMIv2 definitions of 2578 through 2580 described above.
I suggest adding something like:
Therefore, thoughout this document when SNMPv3 is not mentioned 
specifically
the same definitions of SNMPv2 apply for SNMPv3.

Hope this helps,

Harrie