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

["C. M. Heard" <heard@pobox.com>]

On Mon, 8 Oct 2001, Steve Waldbusser wrote:
> (It seems I really do need to send this to both lists to get all
> interested parties).

OK, but I hope Bert doesn't shoot us.

> 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.)

This part of the argument I find a bit hard to accept.  Rather, it
seems to me that

http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-07-rmon.mib

and

http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-hcrmon-07-rmon2.mib

represent updated versions of RMON1 and RMON2 with new capabilities
but which are fully backward compatible with the current versions --
or rather, which would be, if the conformance statements in them were
amended to point out that the enhancements are optional.

> 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.

That part is true.  However, it does so in a way that breaks precedent
with previous methods for publishing MIB modules because -- if I am not
mistaken -- in the past we've not published MIB module fragments as
normative specifications.

> 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".

Here again we part company.  I think that there should always be a
compilable version of every IETF MIB module that is the recognized,
official version.  Up to now, we've done this -- with the narrow
exception of some items that are under IANA control -- by publishing
each version of a MIB module in an RFC.

> 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.

Yes, HCRMON is, but the updated version of RMON-MIB and RMON2-MIB are not.

> 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?".

They haven't changed very much, but they have changed.  In the case
of RMON2, the updated MIB module contains some routine corrections and
clarifications not related to HCRMON that would routinely be published
in the course of advancement.  As for the status of RMON1, it is not by
any means unprecedented for an updated version of a Full Standard to be
published and to re-enter the standards track as a Proposed Standard.
The rfc-index.txt file will note the status of each document, and will
also note that the new one obsoletes the old one (cf. RFC 2821 and RFC
2822, both at Proposed Standard, which obsolete RFC 821 and RFC 822,
both at Full Standard).

> 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).

The solution to that is simple, and fairly standard:  have brief sections
entitled "Changes from RFC 2819" and "Changes from RFC 2021".

> 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.

That's interesting.  I was aware that the WG originally had updated RMON1
and RMON2 drafts, and I didn't find it confusing.

> 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.

Sure.  In fact there are four such IANA-maintained MIB modules:

   MIB module                                Associated RFC
   ----------                                --------------

   IANAifType-MIB                            RFC 2863

   IANA-ADDRESS-FAMILY-NUMBERS-MIB           RFC 2677

   IANA-RTPROTO-MIB (IP Route Protocol MIB)  RFC 2932

   IANA-LANGUAGE-MIB                         RFC 3165

   IANATn3270eTC-MIB                         RFC 2561

Each of these IANA-maintained MIB modules is self-contained and
has nothing except TCs and/or OBJECT-IDENTITIES whose definitions
can stand alone -- i.e., no object or notification  definitions.
The things in them that are subject to change are enumerations or
OIDs -- i.e., things that (like protocol numbers) are more
suitable for registration than publication in an RFC.  The base
MIB modules in the standards-track RFCs IMPORT the appropriate
definitions from these IANA MIBs.  That's why they do not need
to be republished when a number is added or retired.  (The
printer MIB in RFC 1759 does not do things this way but it
probably should if it is re-issued.)  There is plenty of precedent
for this practice in specifications other than MIB modules, and it
is explicitly allowed by RFC 2026.

The situation with respect to the updates in the RMON-MIB and RMON2-MIB
is different.  The things that are being updated are object definitions
that do not stand alone, and the new enumeration values for those objects
extend the semantics of tables in the RMON-MIB and RMON2-MIB to make
them usable with the HC-RMON-MIB module.  That, I think, is something
quite different from adding a new value for ifType, which does not
affect anything else in the IF-MIB.

Once again, let me state that I think that there should always be a
compilable version of every IETF MIB module that is the recognized,
official version.  I think it would be a mistake to make a MIB fragment
normative.  Up to now the de-facto rule has been that recoginized
official version versions of MIB modules are published in RFCs
(apart from the narrow exception of registration items that are under
IANA control).  Maybe that needs to change.  Maybe we should start
putting all IETF MIBs in an official MIB repository.  Maybe this case
is an exception.  But if we are going to change the rules -- whether on
a one-time basis, or permanently -- I think it would be reasonable to
state in writing that we are doing so.

Mike