RE: Last Call: Remote Network Monitoring Management Information Base for High Capacity Networks to Proposed Standard

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

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 mailing lists

Probably the rmonmib mailing list is the best place.

Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> 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
> > iesg@ietf.org or ietf@ietf.org 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
> heard@pobox.com
> 
> 
> 
> 
> 
>