Re: Last Call: Remote Network Monitoring Management InformationBase for High Capacity Networks to Proposed Standard
On Thu, 27 Sep 2001, The IESG wrote: The IESG has received a request from the Remote Network Monitoring Working Group to consider Remote Network Monitoring Management Information Base for High Capacity Networks draft-ietf-rmonmib-hcrmon-09.txt as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by October 10, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-09.txt Updated MIBS can ve obtained via http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-07-rmon.mib http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-07-rmon2.mib I wish to raise four issues with respect to the updated MIBs: one procedural, one technical, and two editorial. Up to now the usual procedure for updating a MIB module that has been published in a standards-track RFC has been to publish a new RFC containing the revised MIB module. The proposed standards action would do something different. The above-mentioned draft draft-ietf-rmonmib-hcrmon-09.txt includes a new MIB module (HC-RMON-MIB) that requires revisions to two existing MIB modules (RMON-MIB and RMON2-MIB). Rather than publish revised versions of the latter MIB modules in new RFCs, the draft contains MIB module fragments specifying the revisions and contains pointers to on-line versions of the complete revised MIB modules. In particular, it points to http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-07-rmon.mib which is a revision of the RON-MIB module published in RFC 2819, currently a Full Standard, and http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-07-rmon2.mib which is a revision of the RMON2-MIB module published in RFC 2021, currently a Proposed Standard. The intent is that when the draft is published as an RFC these updated MIB modules would be posted on-line in a repository maintained by the RFC editor and the pointers would be updated accordingly. The changes to the RMON-MIB and RMON2-MIB modules are relatively modest: as currently written, they amount to adding high-capacity enumerations to hostTopNRateBase in the RMON-MIB and to nlMatrixTopNControlRateBase and alMatrixTopNControlRateBase in the RMON2-MIB, plus some clarifications and fixes for typos in the latter. However, they do tie those MIBs to the HC-RMON-MIB in a normative way via the revised DESCRIPTION clauses. Specifically, the new enumerations for hostTopNRateBase and nlMatrixTopNControlRateBase indicate that the corresponding control table entries pertain to tables in the HC-RMON-MIB, and the new enumerations for alMatrixTopNControlRateBase indicate that the corresponding reports are sorted according to values of objects in the HC-RMON-MIB. The HC-RMON-MIB will be a Proposed Standard; thus, if the revised RMON-MIB and RMON2-MIB modules were to be published in new RFCs, those RFCs would also be Proposed Standards. According to the RMONMIB WG Status slides for IETF #48, the working group wanted only the RateBase objects to cycle at Proposed, not all the other objects. Hence the variant procedure for publishing the updates to the RMON-MIB and RMON2-MIB. While I am sympathetic with the working group's motivation, it does seem to me that updating the RMON-MIB and RMON2-MIB in this way circumvents the following requirement from Section 2.1 of RFC 2026, The Internet Standards Process Revision 3: Each distinct version of an Internet standards-related specification is published as part of the Request for Comments (RFC) document series. In the past I believe that this has been understood to mean that if a MIB module that has been published in a standards-track RFC needs to be updated, then the revised version must be published in its entirety in a new RFC. The proposed standards action would have the effect of changing that understanding. It would therefore seem to be appropriate for the Area Directors to issue a written statement to the community making explicit the policy on publication of new standards-track MIB versions. There is also a minor technical issue regarding the revised RMON-MIB and RMON2-MIB modules. In order to achieve backward compatibility the conformance statements need to contain an OBJECT clauses for hostTopNRateBase, nlMatrixTopNControlRateBase, and alMatrixTopNControlRateBase specifying that if the HC-RMON-MIB is not supported then the only required enumeration values are those that are specified in the current versions (RFC 2819 and RFC 2021) of the MIB modules. The current draft versions have no such OBJECT clauses, implying that all the enumerations (old and new) need to be supported by a conformant implementation. Lastly, two minor editorial matters might be worth noting. First, the revised DESCRIPTION clauses for hostTopNRateBase and nlMatrixTopNControlRateBase should probably mention that
RE: Last Call: Remote Network Monitoring Management InformationBase for High Capacity Networks to Proposed Standard
Could I ask, that if people want to reactto or discuss this that we do the discussion on one mailing list? I suspect many of us are on all 3 lists Probably the rmonmib mailing list is the best place. Bert -Original Message- From: C. M. Heard [mailto:[EMAIL PROTECTED]] Sent: Friday, October 05, 2001 10:32 PM To: IETF Discussion List Cc: RMONMIB Mailing List; MIBS Mailing List Subject: Re: Last Call: Remote Network Monitoring Management Information Base for High Capacity Networks to Proposed Standard On Thu, 27 Sep 2001, The IESG wrote: The IESG has received a request from the Remote Network Monitoring Working Group to consider Remote Network Monitoring Management Information Base for High Capacity Networks draft-ietf-rmonmib-hcrmon-09.txt as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by October 10, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-09.txt Updated MIBS can ve obtained via http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon- 07-rmon.mib http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon- 07-rmon2.mib I wish to raise four issues with respect to the updated MIBs: one procedural, one technical, and two editorial. Up to now the usual procedure for updating a MIB module that has been published in a standards-track RFC has been to publish a new RFC containing the revised MIB module. The proposed standards action would do something different. The above-mentioned draft draft-ietf-rmonmib-hcrmon-09.txt includes a new MIB module (HC-RMON-MIB) that requires revisions to two existing MIB modules (RMON-MIB and RMON2-MIB). Rather than publish revised versions of the latter MIB modules in new RFCs, the draft contains MIB module fragments specifying the revisions and contains pointers to on-line versions of the complete revised MIB modules. In particular, it points to http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon- 07-rmon.mib which is a revision of the RON-MIB module published in RFC 2819, currently a Full Standard, and http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon- 07-rmon2.mib which is a revision of the RMON2-MIB module published in RFC 2021, currently a Proposed Standard. The intent is that when the draft is published as an RFC these updated MIB modules would be posted on-line in a repository maintained by the RFC editor and the pointers would be updated accordingly. The changes to the RMON-MIB and RMON2-MIB modules are relatively modest: as currently written, they amount to adding high-capacity enumerations to hostTopNRateBase in the RMON-MIB and to nlMatrixTopNControlRateBase and alMatrixTopNControlRateBase in the RMON2-MIB, plus some clarifications and fixes for typos in the latter. However, they do tie those MIBs to the HC-RMON-MIB in a normative way via the revised DESCRIPTION clauses. Specifically, the new enumerations for hostTopNRateBase and nlMatrixTopNControlRateBase indicate that the corresponding control table entries pertain to tables in the HC-RMON-MIB, and the new enumerations for alMatrixTopNControlRateBase indicate that the corresponding reports are sorted according to values of objects in the HC-RMON-MIB. The HC-RMON-MIB will be a Proposed Standard; thus, if the revised RMON-MIB and RMON2-MIB modules were to be published in new RFCs, those RFCs would also be Proposed Standards. According to the RMONMIB WG Status slides for IETF #48, the working group wanted only the RateBase objects to cycle at Proposed, not all the other objects. Hence the variant procedure for publishing the updates to the RMON-MIB and RMON2-MIB. While I am sympathetic with the working group's motivation, it does seem to me that updating the RMON-MIB and RMON2-MIB in this way circumvents the following requirement from Section 2.1 of RFC 2026, The Internet Standards Process Revision 3: Each distinct version of an Internet standards-related specification is published as part of the Request for Comments (RFC) document series. In the past I believe that this has been understood to mean that if a MIB module that has been published in a standards-track RFC needs to be updated, then the revised version must be published in its entirety in a new RFC. The proposed standards action would have the effect of changing that understanding. It would therefore seem to be appropriate for the Area Directors to issue a written statement to the community making explicit the policy on publication of new standards-track MIB versions. There is also a minor technical issue regarding the revised RMON-MIB and RMON2-MIB modules. In order to achieve backward compatibility the conformance statements need to contain
