[ipcdn] RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt

[Juergen Quittek <[e-mail]>]

Dan,

Please find the list of changes at the end of this message.

Thanks,

    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


--On 17.06.2004 22:41 Uhr +0300 Romascanu, Dan (Dan) wrote:

> Randy,
>
> Would it be possible for the authors to provide a log of changes relative to RFC 2925?
>
> Regards,
>
> Dan
>
>
>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]]On Behalf Of Randy Presuhn
>> Sent: 17 June, 2004 9:55 PM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: [Disman] Disman WG last call
>> ondraft-ietf-disman-remops-mib-v2-02.txt
>>
>>
>> Hi -
>>
>> As disman WG chair, I'm announcing the start of a two-week
>> working group
>> last call on the Remote Operations MIBs.  The latest version
>> is available at
>> http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-m
>> ib-v2-02.txt
>> Our objective is to advance to Draft Standard.  Off-line I've received
>> word that that we will have at least two implementation reports.  I'm
>> fairly sure there are more out there, so please speak up if
>> you know of
>> an implementation.
>>
>> I'm CC:ing the ipcdn WG mailing list, since we've incorporated some
>> additional conformance material to meet (I hope) their needs.  Please
>> send any comments, including "I've read it and don't object" comments,
>> to the disman WG mailing list at [e-mail].
>>
>> The last call will end on Friday, July second, 2004.  If
>> anyone is committed
>> to reviewing it but would need additional time, let me know
>> and I'll see what
>> we can work out.
>>
>> Randy
>>
>>

======================================================================
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
========================================================================



=======================================
changes from version -00 to version -01
=======================================



========================================================================
12. clarification required for pingMaxConcurrentRequests and
    lookupMaxConcurrentRequests
========================================================================
Problem Description:
------------------------------------------------------------------------
The DESCRIPTION clause of object pingMaxConcurrentRequests does not
explain how to deal with the case that its value is reduced to a
number smaller than the number of active requests.
The same applies to the DESCRIPTION clause of object
lookupMaxConcurrentRequests.
========================================================================
Suggested solution:
------------------------------------------------------------------------
append
   "The limit applies only to new requests being activated.
    When a new value is set, the agent will continue processing
    all the requests already active, even if their number
    exceed the limit just imposed."
to DESCRIPTION clause of object pingMaxConcurrentRequests
and to DESCRIPTION clause of object lookupMaxConcurrentRequests
========================================================================
Status: solution committed
========================================================================


========================================================================
13. No default value for pingCtlTrapGeneration
========================================================================
Problem Description:
------------------------------------------------------------------------
The DESCRIPTION clause of object pingCtlTrapGeneration suggests
that the object "defaults to zero", but there is no DEFVAL clause.
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace in DESCRIPTION clause
       "The value of this object defaults to zero, indicating
        that none of the above options have been selected."
with
       "By default, no bits are set, indicating that
        none of the above options are selected."
and add
    "DEFVAL { {} }  -- no bits set."
========================================================================
Status: solution committed
========================================================================


========================================================================
14. Re-initialization of entries in ping/tracerouteResultsTable unclear
========================================================================
Problem Description:
------------------------------------------------------------------------
The DESCRIPTION clause of objects pingResultsTable and
traceRouteResultsTable do not describe the semantics of
re-initialization.
========================================================================
Suggested solution:
------------------------------------------------------------------------
add to DESCRIPTION clause of object pingResultsTable
       "If object pingCtlAdminStatus already has value enabled(1)
        and if the corresponding pingResultsOperStatus object
        has value completed(3), then successfully writing enabled(1)
        to object pingCtlAdminStatus re-initializes the already
        existing entry in the pingResultsTable.  The values of
        objects in the re-initialized entry are the same than
        the values of objects in a new entry would be."

add to DESCRIPTION clause of object traceRouteResultsTable
       "If object traceRouteCtlAdminStatus already has value
        enabled(1) and if the corresponding
        traceRouteResultsOperStatus object has value completed(3),
        then successfully writing enabled(1) to object
        traceRouteCtlAdminStatus re-initializes the already
        existing entry in the traceRouteResultsTable.  The values of
        objects in the re-initialized entry are the same than
        the values of objects in a new entry would be."

add value completed(3) to SYNTAX clause of pingResultsOperStatus
add value completed(3) to SYNTAX clause of traceRouteResultsOperStatus
========================================================================
Status: solution committed
========================================================================


========================================================================
15. Some objects have syntax Unsigned32 but should be Gauge32
========================================================================
Problem Description:
------------------------------------------------------------------------
Some counters have syntax Unsigned32.  Gauge32 fits better.
========================================================================
Suggested solution:
------------------------------------------------------------------------
Change SYNTAX clause from Unsigned32 to Gauge32 for objects
pingResultsProbeResponses, pingResultsSentProbes,
traceRouteResultsTestAttempts, traceRouteResultsTestSuccesses
========================================================================
Status: solution committed
========================================================================


========================================================================
16. Typo in DESCRIPTION clause of pingTestCompleted
========================================================================
Problem Description:
------------------------------------------------------------------------
The DESCRIPTION clause of pingTestCompleted refers to value
testCompletion(4) of object pingCtlTrapGeneration.  Correct
is testCompletion(2).
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace
         "corresponding pingCtlTrapGeneration object is set to
          testCompletion(4)."
with
         "corresponding pingCtlTrapGeneration object has the
          testCompletion(2) bit set."
========================================================================
Status: solution committed
========================================================================


========================================================================
17. Value of 0 does not make sense for traceRouteCtlInitialTtl
========================================================================
Problem Description:
------------------------------------------------------------------------
The SYNTAX clause of object traceRouteCtlInitialTtl includes 0.
This is not a useful value.
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace
      "SYNTAX         Unsigned32 (0..255)"
with
      "SYNTAX         Unsigned32 (1..255)"
========================================================================
Status: solution committed
========================================================================


========================================================================
18. Irritating description of traceRouteCtlFrequency
========================================================================
Problem Description:
------------------------------------------------------------------------
The DESCRIPTION clause of object traceRouteCtlFrequency contains
an irritating sentence referring to the number of hops per single
traceroute test.
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace
         "The number of hops in a single traceroute test
          is determined by the value of the corresponding
          traceRouteCtlProbesPerHop object.  After a
          single test completes the number of seconds as defined
          by the value of traceRouteCtlFrequency MUST elapse
          before the next traceroute test is started."
with
         "After a single test completes the number of seconds
          as defined by the value of traceRouteCtlFrequency MUST
          elapse before the next traceroute test is started."
========================================================================
Status: solution committed
========================================================================


========================================================================
19. What is a good path?
========================================================================
Problem Description:
------------------------------------------------------------------------
The DESCRIPTION clause of object traceRouteResultsLastGoodPath
does not clearly describe the term 'good' or 'complete' path.
========================================================================
Suggested solution:
------------------------------------------------------------------------
replace DESCRIPTION clause
         "The date and time when the last complete path
          was determined."
with
         "The date and time when the last complete path
          was determined.  A path is complete if responses
          were received or timeout occurred for each hop on
          the path, i.e. for each TTL value from the value
          of the corresponding traceRouteCtlInitialTtl object
          up to the end of the path or - if no reply from the
          target IP address was received - up to the value of
          the corresponding traceRouteCtlMaxTtl object."
========================================================================
Status: solution committed
========================================================================


========================================================================
20. Fixing bug in SYNTAX clause of lookupCtlOperStatus
========================================================================
Problem Description:
------------------------------------------------------------------------
The DESCRIPTION clause of object lookupCtlOperStatus defines
values notStarted(2) and completed(3), but enabled(1) is
missing, although enabled(1) is defined in the DESCRIPTION clause.
========================================================================
Suggested solution:
------------------------------------------------------------------------
add to SYNTAX clause
         "enabled(1),    -- operation is active"
========================================================================
Status: solution committed
========================================================================


========================================================================
21. Missing references
========================================================================
Problem Description:
------------------------------------------------------------------------
Some RFCs are mentioned in DESCRIPTION clauses of the MIB definition,
but not referenced in the Reference section.
========================================================================
Suggested solution:
------------------------------------------------------------------------
add to Normative References
 [RFC2863]   McCloghrie, K. and F. Kastenholz, "The Interfaces Group
             MIB", RFC 2863, June 2000.

 [RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
             for Describing Simple Network Management Protocol (SNMP)
             Management Frameworks", STD 62, RFC 3411, December 2002.

 [RFC3291]   Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder
             "Textual Conventions for Internet Network Addresses", RFC
             3291, May 2002.

add to Normative References
 [RFC2474]   Nichols, K., Blake, S., Baker, F. and D. Black, "Definition
             of the Differentiated Services Field (DS Field) in the IPv4
             and IPv6 Headers", RFC 2474, December 1998.

 [RFC1812]   F. Baker, "Requirements for IP Version 4 Routers", RFC 1812,
             June 1995.
========================================================================
Status: solution committed
========================================================================



=======================================
changes from version -01 to version -02
=======================================



========================================================================
22. The compliance ststements are not well suited for small devices
========================================================================
Problem Description:
------------------------------------------------------------------------
For small devices it might be desirable to support just a single
test per MIB module.  Then creating and deleting table entries is
not required anymore.
========================================================================
Suggested solution:
------------------------------------------------------------------------
Add new MODULE-COMPLIANCY statements pingMinimumCompliance,
traceRouteMinimumCompliance, lookupMinimumCompliance.

The already existing MODULE-COMPLIANCY statements pingCompliance
and traceRouteCompliance are syntactically modified, but
semantically unchanged.

For the following objects pingCompliance and
pingMinimumCompliance differ:
    pingCtlDataFill
    pingCtlFrequency
    pingCtlMaxRows
    pingCtlTrapGeneration
    pingCtlProbeFailureFilter
    pingCtlTestFailureFilter
    pingCtlDescr
    pingCtlByPassRouteTable
    pingProbeHistoryTime

For the following objects traceRouteCompliance and
traceRouteMinimumCompliance differ:
    traceRouteCtlByPassRouteTable
    traceRouteCtlDontFragment
    traceRouteCtlInitialTtl
    traceRouteCtlFrequency
    traceRouteCtlDescr
    traceRouteCtlMaxRows
    traceRouteCtlTrapGeneration
    traceRouteCtlCreateHopsEntries
    traceRouteCtlRowStatus
    traceRouteHopsLastGoodProbe

For the following objects lookupCompliance and
lookupMinimumCompliance differ:
    lookupCtlRowStatus

Add new section
   "3.4.  Conformance

    Each of the three MIB modules defined in this document has two
    compliancy statements, one for full compliancy and one for minimum
    compliancy.  The minimum compliancy statements are intended to be
    applied to implementation for devices with very limited resources.
    The main difference between full and minimum compliancy is that for
    minimum compliancy dynamic creation and deletion of table entries is
    not required while it is required for full compliancy."
========================================================================
Status: solution committed
========================================================================


========================================================================
23. disabling of lookupPurgeTime
========================================================================
Problem Description:
------------------------------------------------------------------------
There is no value defined for object lookupPurgeTime that disables
the function of automatich entry deletion.  Also, the use of value
0 is questionable.
========================================================================
Suggested solution:
------------------------------------------------------------------------
Add to DESCRIPTION clause
         "A value of 0 indicates that automatic deletion
          of entries is disabled."
========================================================================
Status: solution committed
========================================================================




_______________________________________________
IPCDN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn