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

[Steve Waldbusser <waldbusser@nextbeacon.com>]

(It seems I really do need to send this to both lists to get all
interested parties).

We decided that the current design is the best based on a couple of
basic concepts:

1) Neither the RMON1 standard or the RMON2 standard have changed as a
result of HCRMON. (Yes, the MIB modules are being revised, but those
standards themselves aren't changing - i.e. conformance requirements
haven't changed.)

2) The normative specification is contained *entirely* in the
hcrmon-09 draft. In other words, hcrmon-09 contains everything 2
implementors would need to know to develop conformant and
interoperable implementations.

A reviewer of the MIB felt that it would be helpful to the reader to
provide a parseable copy of the entire MIB that people could load
directly into their compilers. After a few iterations, we compromised
on the current document which says:
"For convenience, updated MIB modules containing these objects may be
 found at:" (it then lists the URLs at www.ietf.org)

So even though the RMON1.mib and RMON2.mib documents exist, they are
not a part of the specification. They are optional documentation we
included "for convenience".

I believe your argument is that RFC 2026 dictates that the entirety of
a standard be contained in the RFC series. I have no quarrel with this
premise but as I argue above, the entirety of HCRMON *is* contained in
hcrmon-09.txt.

The above argues why it is OK to proceed this way. Equally important
is why we believe this way is the *best* way, or in other words, why
would it be a bad thing to republish RMON1 and RMON2 in RFCs:

1) RMON1 and RMON2 haven't changed as a result of this. Seeing them in
new RFCs would cause confusion such as "Which RMON1 is current?" or
"So does RMON go back to proposed from full?".

2) RMON1 and RMON2 together comprise 220 pages of text. The
enumeration extensions are about 1 page of text. Burying the 1
"interesting" page in 220 pages of text is not what I'd call "helpful"
to the reader - in fact it completely obfuscates the essence of the
change. (If we were talking about a new version of RMON1 or RMON2,
maybe this would be unavoidable, but we're not).

Originally we tried to republish the slightly modified contents of
RMON1 and RMON2 and it caused the confusion described above. Among the
confused parties was the IESG.

Finally, note that many years ago when we were faced with a similar
situation with the evolving ifType enumeration, we decided it was
*not* sensible to republish MIB2/ifMIB in its entirety every time the
enumeration changed. As a result, the enumeration list was updated
outside the base specification.


Steve


"C. M. Heard" wrote:
> 
> 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