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