RE: RE: Historic confusion over Ethernet MIBs!

On Tue, 7 May 2002, Andrew Smith wrote:

> A couple of points on this issue:
> 
> 1. There is a mismatch between the base IEEE 802.3 "Ethernet" specification
> numbering space and the RFC numbering space used to document these MIBs for
> 802.3. A mapping is needed between them.

In other words, you'd like to see a table somewhere that lists, for
each RFC containing a revision of the EthernetLike-MIB, the version
of IEEE Std 802.3 to which it corresponds?  (Each EthernetLike-MIB
RFC does contain that information.)

> 2. The underlying IEEE 802.3 specification is a moving target, a living
> document.

Which is a different model than in used in the Internet standards
process.

> 3. The underlying 802.3 specifications have always been, and will continue
> to be for the foreseeable future, "re-affirmed" every few years.

No, the trend over the last few years has been for the 802.3 publication to
be REVISED, as in adding major new features (like 100 Mb/s, 1000 Mb/s, and
now 10 Gb/s).

> 4. RFC 1643 stands as a self-contained snapshot of Ethernet management in
> 1994, both the underlying technology (10Mbps Ethernet) and the grammar used
> to describe the manageable objects in it (SMI version 1). Later RFCs
> translated it to SMIv2 and played around with its objects a bit but none of
> them contains the phrase "Obseletes RFC 1643".

No, but in retrospect I think RFC 2358 should have.

> So, what to do about it?
> 
> Option A) align the numbering schemes: this means introducing a "version
> number" for these MIBs, if not in the RFC document boilerplate then, at
> least, in the SMI module(s) contained therein. Conformance is then to be
> claimed with the thing with the version, probably not just with the RFC
> number. This would need some re-education of marketing folks :-) I'd suggest
> that there be some sort of matchup between IEEE 802.3 "clause" numbers and
> the unit of conformance since, typically, 802.3 does not go back to change
> an existing clause but adds new clauses with new management functionality.

Something like this already exists:  it's called a MODULE-COMPLIANCE
invocation, it has a name and and OID, and implementors can claim to
conform to it.

As for matching this up with 803.3 clause numbers:  it turns out that
Clause 30, which contains the 802.3 protocol-neutral MIB object
definitions, seems to get updated with every revision of 802.3.  Its 
subclauses figure prominently in the REFERENCE clauses of the
EthernetLike-MIB.

> Option B) toss this work over the fence to IEEE 802.3: I think they might
> now be ready to accept SNMP/SMI as mainstream (GDMO doesn't really have much
> of a following, even amongst those purists, any more). IEEE 802.1 and 802.3
> have already bitten this bullet and written SMIv2 MIBs for themselves and
> included them in e.g. 802.1X (network access control) and 802.3ad (link
> aggregation) specs.
> 
> Option C) my least favourite: write a BCP-AS that is a living document,
> providing the glue to match up the appropriate versions of 802.3 and of the
> RFCs. It needs to be revised every time one of them changes and its WG,
> therefore, become vampire-like and never gets to sleep :-)

Guess what:  that's what essentially we've been doing, except that instead
of BCP the MIB document just recycles at Proposed Standard.  That always
happens if you add objects to a MIB module.  Sometimes it can be avoided by
making supplemental MIB modules, but that approach did not seem appropriate
in this case.
 
> Option D) do nothing: actually, not a bad approach. Implementors and users
> make their own decisions about whether this week's version of the ID, a
> draft-, a proposed- or a full-standard are what they build or purchase. The
> statement in the RFC-to-Historic draft about
>    "Having it remain an Internet Standard while the replacement RFCs make
> their
>    way through the standards track serves no useful purpose and may even
>    have the undesirable effect of encouraging vendors to implement it
>    instead of its more up-to-date replacements."
> is too myopic for my liking and ignores the status that full-standard is
> supposed to carry. If the more up-to-date replacements are so wonderful then
> we should put our efforts into getting full-standard status for them (or in
> improving the process to make that easier/quicker) and in getting the magic
> phrase "Obseletes RFC 1643" placed in a full-standard RFC.
> 
> i.e. I do not think that "Historic" is the right approach here. But whatever
> is done, do it right, because this issue is not going away any time soon.

What useful purpose is served by maintaining the designation of Internet
Standard for a document, such as RFC 1643, that has been superseded by
other documents?  To me, _that_ seems to ignore the status that full
standard is supposed to carry.

//cmh