[Disman] update of RFC 2925

[Juergen Quittek <[e-mail]>]

I posted an update of RFC 2925 in
draft-ietf-disman-remops-mib-v2-00.txt.

It addresses all issues that has been raised on the mailing list since
publication of the RFC and it addresses some updates required because
referenced RFCs were updated themselves. Please see the full list of
changes below.

I still did not review Section 3 "Structure of the MIBs" ans Section 5
"Security Considerations" as carefully as I would have liked to.

Please have a look at the document and send me your comments.

I intend to post another version two weeks after the IETF meeting.

See you there,

    Juergen
-- 
Juergen Quittek        [e-mail]        Tel: [phone]
NEC Europe Ltd.,       Network Laboratories        Fax: [phone]
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.ccrle.nec.de


##########################################################################


======================================================================
Changes in draft-ietf-disman-remops-mib-v2-00.txt compared to RFC 2925
======================================================================



========================================================================
1. typo in description of pingTestCompleted
========================================================================
Problem Description:
------------------------------------------------------------------------
>From RFC Errata web page
Reported by: Randy Presuhn; [e-mail]
Date: Tue, 26 Mar 2002 15:16:54 -0800

In Section 4.1:

   "Generated at the completion of a ping test when the
   corresponding pingCtlTrapGeneration object is set to
   testCompletion(4)."

Should be:

   "Generated at the completion of a ping test when the
   corresponding pingCtlTrapGeneration object is set to
   testCompletion(2)."
========================================================================
Suggested solution:
------------------------------------------------------------------------
   obvious
========================================================================
Status: solution committed
========================================================================



========================================================================
2. description of pingCtlDataSize ignores IPv6
========================================================================
Problem Description:
------------------------------------------------------------------------
Currently, RFC 2925 says:
 pingCtlDataSize OBJECT-TYPE
    SYNTAX      Unsigned32 (0..65507)
    UNITS       "octets"
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Specifies the size of the data portion to be
        transmitted in a ping operation in octets.  A ping
        request is usually an ICMP message encoded
        into an IP packet.  An IP packet has a maximum size
        of 65535 octets.  Subtracting the size of the ICMP
        or UDP header (both 8 octets) and the size of the IP
        header (20 octets) yields a maximum size of 65507
        octets."
    DEFVAL { 0 }
    ::= { pingCtlEntry 5 }

This has caused some concern that the MIB isn't right for IPv6.
========================================================================
Suggested solution:
------------------------------------------------------------------------
Replace description by
   "Specifies the size of the data portion to be
   transmitted in a ping operation in octets.  Whether or
   not this value can be applied depends on the selected
   implementation method for performing a ping operation
   indicated by pingCtlType in the same conceptual row.
   If the method used allows applying the value contained
   in this object, then it MUST be applied.  If the specified
   size is not appropriate for the chosen ping method, the
   implementation SHOULD use whatever size (appropriate to
   the method) is closest to the specified size.

   The maximum value for this object was computed by
   substracting the smallest possible IP header size of
   20 octets (IPv4 header with no options) and the UDP
   header size of 8 octets from the maximum IP packet size.
   An IP packet has a maximum size of 65535 octets
   (excluding IPv6 Jumbograms)."
========================================================================
Status: solution committed
========================================================================



========================================================================
3. description of traceRouteCtlDataSize ignores IPv6
========================================================================
Problem Description:
------------------------------------------------------------------------
Currently, RFC 2925 says:
 traceRouteCtlDataSize OBJECT-TYPE
    SYNTAX      Unsigned32 (0..65507)
    UNITS       "octets"
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Specifies the size of the data portion of a traceroute
        request in octets.  A traceroute request is essentially
        transmitted by encoding a UDP datagram into a
        IP packet. So subtracting the size of a UDP header
        (8 octets) and the size of a IP header (20 octets)
        yields a maximum of 65507 octets."
    DEFVAL { 0 }
    ::= { traceRouteCtlEntry 6 }

This has caused some concern that the MIB isn't right for IPv6.
========================================================================
Suggested solution:
------------------------------------------------------------------------
Replace description by
        "Specifies the size of the data portion of a traceroute
        request in octets.  If the RECOMMENDED traceroute method
        (UDP datagrams as probes) is used, then the value
        contained in this object MUST be applied.  If another
        traceroute method is used for which the specified size
        is not appropriate, then the implementation SHOULD use
        whatever size (appropriate to the method) is closest to
        the specified size.

        The maximum value for this object was computed by
        substracting the smallest possible IP header size of
        20 octets (IPv4 header with no options) and the UDP
        header size of 8 octets from the maximum IP packet size.
        An IP packet has a maximum size of 65535 octets
        (excluding IPv6 Jumbograms)."
========================================================================
Status: solution committed
========================================================================



========================================================================
4. SNMP boilerplate outdated
========================================================================
Problem Description:
------------------------------------------------------------------------
   Section 2 on "The Internet-Standard Management Framework" is
   outdated.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   Replace with new one.
   This implies an update of the reference section.
========================================================================
Status: solution committed
========================================================================



========================================================================
5. References need to be split in normative and informational ones.
========================================================================
Problem Description:
------------------------------------------------------------------------
   clear
========================================================================
Suggested solution:
------------------------------------------------------------------------
7.  Normative References

[RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M. and S. Waldbusser, "Structure of Management
            Information Version 2 (SMIv2)", STD 58, RFC 2578, April
            1999.

[RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2",
            STD 58, RFC 2579, April 1999.

[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M. and S. Waldbusser, "Conformance Statements for
            SMIv2", STD 58, RFC 2580, April 1999.

8.  Informative References

[RFC2119]   S. Bradner "Key words for use in RFCs to Indicate
            Requirement Levels", RFC 2119, March 1997.

[RFC862]    J. Postel "Echo Protocol", STD 20, RFC 862, May 1983.

[RFC792]    J. Postel "Internet Control Message Protocol", RFC 792,
            September 1981.

[RFC3410]   Case, J., Mundy, R., Partain, D. and B. Stewart,
            "Introduction and Applicability Statements for Internet-
            Standard Management Framework", RFC 3410, December 2002.

[RFC3415]   B. Wijnen, R. Presuhn, K. McCloghrie, "View-based Access
            Control Model (VACM) for the Simple Network Management
            Protocol (SNMP)", STD 62, RFC 3415, December 2002.
========================================================================
Status: solution committed
========================================================================



========================================================================
6. clarify structure of Section 1 "Introduction"
========================================================================
Problem Description:
------------------------------------------------------------------------
   The structure of the introduction would be clearer if subsections
   were used.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   insert subsection headers
      1.1. Ping
      1.2. Traceroute
      1.3. Lookup
      1.4. Remote Operations
========================================================================
Status: solution committed
========================================================================



========================================================================
7. context of remote operations explanation not clear
========================================================================
Problem Description:
------------------------------------------------------------------------
   At the end of Section 1 "Introduction" the remote operations scenario
   is described. The description starts without explaining the context.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace "Consider the following diagram:" by
   "The MIB modules defined in this document allow a management station
   to initiate ping, traceroute and lookup operations remotely.  The
   basic scenario is illustrated by the following diagram."
========================================================================
Status: solution committed
========================================================================



========================================================================
8. diagram explaining remote operations scenario
========================================================================
Problem Description:
------------------------------------------------------------------------
   The diagram at the end of Section 1 "Introduction"

   +--------------------------------------------------------------------+
   |                                                                    |
   |           Remote ping, traceroute,  Actual ping, traceroute,       |
   |       +-----+or Lookup op.    +------+or Lookup op.    +------+    |
   |       |Local|---------------->|Remote|---------------->|Target|    |
   |       | Host|                 | Host |                 | Host |    |
   |       +-----+                 +------+                 +------+    |
   |                                                                    |
   |                                                                    |
   +--------------------------------------------------------------------+

   uses "local host" and "remote host". In order to align it with the
   SNMP management framework, these terms should be replaced by
   "management station" or "managed node", respectively.

   also it would increase clarity if the remote initiation of operations
   was separated from reciving results.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace diagram by

    +-------+           +-------+           +-------+
    |       |---------->|       |           |       |
    |       | initiate  |       |---------->|       |
    | Mgmt. | operation |Managed|  perform  |Target |
    |Station| remotely  | Node  | operation | Host  |
    |       |           |       |           |       |
    |       |<----------|       |           |       |
    +-------+  receive  +-------+           +-------+
              result of
              operation

    and update text in following paragraph accordingly.
========================================================================
Status: solution committed
========================================================================



========================================================================
9. RFC 2575 (VACM) obsoleted
========================================================================
Problem Description:
------------------------------------------------------------------------
   RFC 2575 (VACM) is referenced several times in the document.
   RFC 2575 has been obsoleted by RFC 3415.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   replace RFC 2575 by RFC 3415 in text, MIBs and reference sections.
========================================================================
Status: solution committed
========================================================================



========================================================================
10. obsoleted RFCs metioned in IPORT sections
========================================================================
Problem Description:
------------------------------------------------------------------------
   RFC 2571 imported by DISMAN-PING-MIB is obsoleted by RFC 3411.
   RFC 2571 imported by DISMAN-TRACEROUTE-MIB is obsoleted by RFC 3411.
   RFC 2571 imported by DISMAN-NSLOOKUP-MIB is obsoleted by RFC 3411.
   RFC 2851 imported by DISMAN-PING-MIB is obsoleted by RFC 3291.
   RFC 2851 imported by DISMAN-TRACEROUTE-MIB is obsoleted by RFC 3291.
   RFC 2851 imported by DISMAN-NSLOOKUP-MIB is obsoleted by RFC 3291.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   The comment in DISMAN-PING-MIB IMPORT section needs to be updated.
   The comment in DISMAN-TRACEROUTE-MIB IMPORT section needs to be updated.
   The comment in DISMAN-NSLOOKUP-MIB IMPORT section needs to be updated.
   The comment in DISMAN-PING-MIB IMPORT section needs to be updated.
   The comment in DISMAN-TRACEROUTE-MIB IMPORT section needs to be updated.
   The comment in DISMAN-NSLOOKUP-MIB IMPORT section needs to be updated.
========================================================================
Status: solution committed
========================================================================



========================================================================
11. Update contact info in MIB modules
========================================================================
Problem Description:
------------------------------------------------------------------------
   So far Kenneth served as contact. Now Juergen edits the docuemnt
   and takes over.
========================================================================
Suggested solution:
------------------------------------------------------------------------
   Replace Kenneth by Juergen in all three MIB modules.
========================================================================
Status: solution committed
========================================================================