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
>