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