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

[Andy Bierman <abierman@cisco.com>]

At 11:27 PM 10/5/2001 +0200, Wijnen, Bert (Bert) wrote:
>Could I ask, that if people want to reactto or discuss this
>that we do the discussion on one mailing list?
>I suspect that many of us are on all 3 mailing lists.
>
>Probably the rmonmib mailing list is the best place.


I originally responded on the rmonmib list, but I think the
general MIBs list is more appropriate.   The people who
subscribe to the rmonmib list came up with the proposal
being reviewed, so there's no point in sending it back there
for discussion.

There are some very high-level issues being avoided here, which should
be discussed in a general forum.

The WG wanted to avoid the incorrect perception that all of functionality
  (in a proposed RFC 2819 update) was new and unstable.  Almost all of the
  functionality in this proposed PS update is actually at Full Standard level.

The WG wanted to avoid a significant cut-and-paste effort, because it
was viewed as bad MIB design to duplicate the TopN control mechanisms
just to avoid editing the RMON-MIB module.

It's been pointed out that the current Standards Process (2026) does not
allow for any other mechanisms to update a MIB module besides cycling
at PS or cloning MIB objects.

After 2 years of delay, it's obvious to me that we would have been better off
recycling RMON at PS than attempting to alter the standards process.  I 
think there
are larger issues here about the overall value and effectiveness of the 3-tier
standards track model and the lack of facilities for reusable semantic 
content .
SMIng is addressing the latter issue to some degree, at least.

It's unfortunate that we are forced to choose between higher standards track
designation and good MIB design.


>Bert

Andy



> > -----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
> >
> >
> >
> >
> >
> >
>
>_______________________________________________
>RMONMIB mailing list
>RMONMIB@ietf.org
>http://www1.ietf.org/mailman/listinfo/rmonmib