ietf
[Top] [All Lists]

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

2001-10-05 19:10:03
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(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)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(_at_)pobox(_dot_)com








<Prev in Thread] Current Thread [Next in Thread>
  • Re: Last Call: Remote Network Monitoring Management Information Base for High Capacity Networks to Proposed Standard, C. M. Heard <=