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

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Inline

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: Monday, October 08, 2001 9:33 PM
> To: MIBS Mailing List
> Cc: RMONMIB Mailing List
> Subject: Re: Last Call: Remote Network Monitoring Management 
> Information
> Base for High Capacity Networks to Proposed Standard
> 
> 
> 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.
> 
Nope... I am supporting this approach.
Not 100% sure about all other IESG members, but I think I can defend
the approach if I get challenged.

> > 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.
> 
So is the proposal here to update the DESCRIPTION clause of the
conformance statements to point that out? Any proposed text that
we could consider/evaluate?

> > 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.
> 
It probably is indeed the first time we do it this way. But we believe
this is within the rules for our standardization process.

> > 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.
> 
The earlier RMON1 and RMON2 mibs are still extractable and compilable
from the original RFCs. The new rmon1/rmon2 mibs could 
- be build manually from the original mibs plus the changes in
  hcrmon document
- picked up from the IETF side where they are provided 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.
> 
> 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.
> 
But various people in the IESG did... 
Imagine someone who is not as close to MIBs as we are.

> > 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.
>
That is in fact being considered.

> 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 find the word "rules" a bit strong here. We have been discussion this
approach for a while with various people. This is the first document to
which we apply this approach. While we do this we get comments like yours.
This is good. We need to understand all the implications and we need
to be able to convince everyone (or better we need (rough) consensus)
that this is the right (or an acceptable/pragmatic) approach.
I think it is. Are we getting closer to convince you?

> Mike
> 
Bert