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

Thank you Harry.

dbh

> -----Original Message-----
> From: Harrie Hazewinkel [mailto:[email protected]]
> Sent: Wednesday, January 08, 2003 5:21 AM
> To: WG IETF snmpv3
> Cc: Harrington, David
> 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?
> 
> 
> >    Table Of Contents
> [snip]
> >    B. Changes From RFC1908 
> ........................................   55
> 
> What about the changes since RFC2576?
> Mentioned already by, "C. M. Heard" <[email protected]>
> 
> > 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.
> 
> >    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.
> This section 1.4 seems also the be hanging between section 2 and 3.
> 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.
> 
> > 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.)
> 
> >    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.
> 
> > 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.
> 
> > 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??
> 
> > 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.
> 
> > 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??
> 
> >        -  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.
> 
> > 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.
> 
> cheers,
> 
> Harrie
> ------------------------------------------------------------------
> Author of MOD-SNMP, enabling SNMP management of Apache HTTP server
> 
>