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:heard(_at_)pobox(_dot_)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(_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