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

[Andy Bierman <abierman@cisco.com>]

At 12:33 PM 10/8/2001 -0700, C. M. Heard wrote:
>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.


I agree RMON-1 and RMON-2 could be republished such that the
existing conformance statements could be preserved, and new
HC-RMON specific statements added. The WG felt that in this
case the deltas were so small, that we would create a lot of
confusion if the FS RMON-MIB went back to PS. Of course,
that was back in early '99.

As I said in my previous mail, the delays have already caused
customer confusion.  Many vendors are shipping the HC-RMON
MIB (it hasn't changed in over 2 years) and they have a twice
published, twice expired I-D to point at.  I don't think our
proposed solution will make matters worse, but if enough people
think republishing the RMON RFCs would be less confusing
than the HC-RMON solution. then I would support that approach.



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


We want the RMON-MIB module to contain the objects that are
normative for conformance with the RMON-1.  These requirements
have not changed in 10 years and they aren't changing now.

The enum values added to the hostTopNRateBase object that point to 64-bit 
counters:
     hostTopNHCInPkts(8),
     hostTopNHCOutPkts(9),
     hostTopNHCInOctets(10),
     hostTopNHCOutOctets(11)

The 4 enums are normative for the HC-RMON MIB, not the RMON-MIB.
A conformant HC-RMON implementation must support the hostTopNRateBase
object which includes enum values 8-11, and a conformant RMON implementation
will never be required to support enum values 8-11.

Since the SMI does not allow us to extend MIB objects (only MIB modules),
we cannot publish this extension in the usual manner.  If we had originally
designed the MIB to use registration OIDs instead of an enumerated integer,
we would not be having this discussion now, but we didn't.  The SMI allows
OID values to be declared independently, unlike an enumerated integer,
which must be declared in an OBJECT-TYPE or TEXTUAL-CONVENTION
macro.

BTW, what's the normative reference for the IANAifType-MIB module?
Is it RFC 1573 or http://www.iana.org/assignments/ianaiftype-mib?
If it's 1573, it's way out of date.   Not all normative references
are contained in RFCs.


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

I don't place much value in the 3-tier standards track model for MIBs.
I suspect the conformance for SMTP changed between 821 and 2821,
and if it did, then going back to PS is appropriate.  Protocol specs
are not overly constrained like MIB modules. It's just text and you
can put it anywhere you want. That's why there's so many protocol
extension RFCs.  I would rather publish the HC-RMON extensions
to RMON-1 and RMON-2 in the same manner, but the SMI does not
provide this capability.


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


I don't see how a distributed list of enumerations which define normative
semantics for any object of syntax IANAifType is somehow special, or
somehow different than other enumerated integer MIB objects.


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

I agree that the rules should be constrained and written down.
Maybe the HC-RMON MIB is a red herring.  It extends most
32-bit RMON functions to include 64-bit counters as well
as 32-bit overflow counters.  In every case, the existing 32-bit
control tables are used since they are in no way dependent on
the counter size in the associated data tables.  In 2 cases,
new enumerations had to be added to existing control objects.
Maybe we should have cloned those objects (and all the
objects that reference those objects) but the WG did not
fully consider the RFC publication consequences of this MIB design
issue (back in '98?).


>Mike

Andy