RE: Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt
Juergen Quittek <[email protected]>
| Newsgroups | gmane.ietf.disman,gmane.ietf.ipcdn |
|---|---|
| Message-ID | <2147483647.1087603299@[192.168.1.6]> |
Dan,
Please find the list of changes at the end of this message.
Thanks,
Juergen
--
Juergen Quittek [email protected] Tel: +49 6221 90511-15
NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55
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: [email protected]
>> [mailto:[email protected]]On Behalf Of Randy Presuhn
>> Sent: 17 June, 2004 9:55 PM
>> To: [email protected]
>> Cc: [email protected]
>> 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 [email protected].
>>
>> 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; [email protected]
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
========================================================================