RE: RE: Historic confusion over Ethernet MIBs!

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.

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

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

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

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.

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

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.

Andrew Smith



-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
C. M. Heard
Sent: Monday, May 06, 2002 1:14 PM
To: Hubmib Mailing List
Cc: Bob Braden; [email protected]; [email protected]
Subject: Re: [Hubmib] RE: Historic confusion over Ethernet MIBs!


On Mon, 6 May 2002, Bob Braden wrote:
> What does a "standard" mean?  And when does one cease to be a
> standard?  Consider the ANSI standard for buggy whips (if there is
> one); would it not still be a standard today, regardless of its current
> lack of popularity?

Most likely not.  ANSI has a policy that after five years a standard
must either be re-affirmed, revised, or retired.  It is not unusual
for ANSI standards to be retired.

> When we set up the Internet standards process (which happened long
> before RFC 2026 or POISED) we distinguished Technical Specifications
> from Applicability Statements.  A TS tells you what, an AS tell you
> when to use it in the real world.  I still believe this is the logical
> approach.  A TS may be a Standard, but a later AS may say, DON'T DO
> THAT -- or, as the system is supposed to work, it is OBSOLETED by a
> later Standard.

I'd like to make couple of points.  First, while respecting the
conceptual distinction bewteen an AS and a TS, RFC 2026 acknowledges
that in practice both may be contained in the same document.  That
is the case with most MIB documents, including the ones under discussion.

Second, in Section 4.2.4 RFC 2026 defines "Historic" as follows:

   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be
   obsolete is assigned to the "Historic" level.

Note that the term "specification", as used above, may refer to
either a TS or an AS.

Now, RFC 1643 is obsolete _both_ in its lack of managed objects
for 100 Mb/s, 1000 Mb/s, and 10 Gb/s interfaces _and_ in it
lack of conformance statements that apply to such interfaces ...
in other words, both its TS and AS aspects have been superseded
by the most recent EthernetLike-MIB documents, which applies to
all of those interfaces plus the 10 Mb/s interfaces that are
covered by RFC 1643.  The definition of Historic from certainly
seems to apply in this case.

> [ ... ] I oppose reflexively using Historic when a specification has
> merely fallen out of current vogue.  We often these days have multiple
> generations of specs interoperating -- Widget 2, Widget 3, ...  As long
> as Widget 2 continues to be in productive use in the Internet, I don't
> see the logic of making its specification, currently a Standard, into
> Historic.  The proper action in that case is to write an AS that says
> "Implement Widget 3 in new code, but running Widget 2 is still
> permissible".  And I would not use the Historic bit as a short-hand in
> such a case.  [ ... ]

Those considerations do not apply here.  Every MIB object defined in RFC
1643 is also present in the revised specifications that supersede it,
along with detailed conformance information that state for all existing
Ethernet interface types -- including those covered by RFC 1643 -- which
objects are required, which are optional, which don't apply, and which
are considered to be obsolete.  So we don't lose anything by retiring
RFC 1643.

If <draft-ietf-hubmib-1643-to-historic-00.txt> does not make this
sufficiently clear, please let us know what additional explanation
you think is needed.

Mike


_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib