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

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 protected]]
> > 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 protected]>
> 
> 
> 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
> > 
>