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 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 the > hostTopNHighCapacityTable and nlMatrixTopNHighCapacityTable reside > in the HC-RMON-MIB. Second, the DataSource and addressMapSource > DESCRIPTION clauses in the revised RMON2-MIB should refer to [RFC2863] > rather than [17] as the source of the definition of ifIndex. > > Mike > -- > C. M. Heard > [EMAIL PROTECTED] > > > > > >
