Subject: [Hubmib] RE: Historic confusion over Ethernet MIBs!

From: Bob Braden <[email-masked]>
Date: Mon, 6 May 2002 16:28:18 GMT

*> 
  *> I have copied the hubmib list to the thread, as I think the subject is of interest for the broad WG community.
  *> 
  *> My question to Bob and the IESG is why should an Applicability Statement RFC have more visibility than marking RFC 1643 as Historic? I do not mind to follow whatever is the IESG practice in such cases, but I agree with Bert that we should do both. 
  *> 
  *> Regards,
  *> 
  *> Dan
  *> 

Dan,

Let me reply somewhat carefully, after taking off my RFC Editor project
hat.  You will note that I am still wearing a funny hat-like object,
that is my Internet-fossil hat.

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?

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.

Now, there are practical realities in the world.  One reality is that
the IETF standards process, as designed and documented, does not work
very well: very few standards track documents make it through the
process to Standard status.  Another reality is that it seems much
easier to just demote a Standard to Historic than to write an AS. But
in my observation over many years of this stuff, the situation is often
much more complex than one bit of information -- and Historic would be
only one bit.  A newbie trying to figure out all that you know about
the area would like/deserves/needs some guidance in understanding the
relationship among the relevant RFCs.  That's work, but it's important
work.  One good rule might be to generally require an explanatory AS
whenever a standards-track TS is moved to Historic.

So, you ask, why not move your protocol to Historic AND write an AS?
There may be circumstances where this is the best answer (and perhaps
yours is one of them, I don't know.)  One could argue that when further
*use* of a Standard specification is a REALLY BAD IDEA(!!) because it
threatens the stability and/or interoperability of the Internet, then
marking it Historic as well as writing a strong Thou-Shalt-Not AS
would be the best course.

However, 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.  I oppose even more strongly moving a Standard to Historic
just because it is not in vogue any more.  Circumstances change, and we
might find in the future that is has become useful again.  And there
may well be particular circumstances where the seldom-used Standard is
still relevant to someone, maybe in some particular corner of the
Internet.

So from all the considerations above, I am suspicious of the
correctness of moving a specification to Historic.  It happens that
some in the IESG has a tendency to move standards track documents
wholesale to Historic, so there is a disagreement.

In summary, I say AS yes, Historic maybe.

Bob Braden

*> > -----Original Message-----
  *> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
  *> > Sent: Saturday, May 04, 2002 12:12 AM
  *> > To: Bob Braden; [email-masked]; [email-masked]
  *> > Cc: [email-masked]; Romascanu, Dan (Dan); [email-masked]
  *> > Subject: RE: Historic confusion over Ethernet MIBs!
  *> > 
  *> > 
  *> > >   *> 
  *> > >   *> That's right.  Let me add two other things:
  *> > >   *> 
  *> > >   *> 1.) Some implementors have reportedly uses 1643 in lieu of 2665
  *> > >   *> because 1643 it is at full standard while 2665 is at proposed.
  *> > >   *> 
  *> > >   *> 2.) The hubmib WG is getting ready to issue a new revision that
  *> > >   *> will obsolete 2665 (the "RFC xxxx" referred to in the draft).
  *> > >   *> It will also be at proposed because it adds new stuff to the
  *> > >   *> MIB to support 10Gb/s Ethernet.
  *> > >   *> 
  *> > >   *> The main reason for sending 1643 to Historic is to signal to
  *> > >   *> implementors that they should not use it and should use the
  *> > >   *> most up-to-date document instead.
  *> > > 
  *> > > There is a concern that those vendors who do not pay enough 
  *> > attention
  *> > > to figure it out probably won't pay attention to the Historic
  *> > > designation either.  A more effective approach might be to write a
  *> > > short RFC that is an "Applicability Statement for Ethernet 
  *> > MIBs", with
  *> > > MUST, MUST NOT, SHOULD NOT, etc
  *> > > 
  *> > > Using Historic status in this manner in lieu of an AS is believed by
  *> > > some of us to be a questionable concept, and is not the way we have
  *> > > proceeded in the past.
  *> > > 
  *> > Bob, are you saying that the 1643 should not be reclassified Historic?
  *> > I don't think I agree with that.
  *> > 
  *> > If you are saying that we should write an AS and in there explain
  *> > the relationship of the various MIBs and also explain why 1643
  *> > goes historic, that I can live with.
  *> > 
  *> > Bert
  *> > > Bob Braden
  *> > > 
  *> > 
  *> > >   *> 
  *> > >   *> > Now.. would it help if we ask the authors to explain 
  *> > > this in the
  *> > >   *> > document that they want to publsih explaining why 1643 goes
  *> > >   *> > to historic (in fact they may already do so.. but I need to
  *> > >   *> > check).
  *> > >   *> 
  *> > >   *> The draft (which is intended to be published concurrently with
  *> > >   *> the new "RFC xxxx" that obsoletes 2665) does say (in the 
  *> > > abstract)
  *> > >   *> that RFC 1643 is at Standard while "RFC xxxx" is at 
  *> > Proposed but
  *> > >   *> neglects to say that the other documents have been 
  *> > obsoleted and
  *> > >   *> it does not mention 2666 at all.  We can add that if you want.
  *> > >   *> 
  *> > >   *> On Friday, May 03, 2002 Bob Braden wrote:
  *> > >   *> > Maybe they need to write a short Applicability 
  *> > > Statement RFC that
  *> > >   *> > straighens it all out?
  *> > >   *> 
  *> > >   *> I don't mind turning the draft into "Applicability 
  *> > Statement for
  *> > >   *> RFC 1643 to Historic" or something like that and adding more
  *> > >   *> explanation.  However it would be helpful if you will be
  *> > >   *> specific about what you want us to change.  Also, I'd like to
  *> > >   *> request that suggestions be cc:'d to the hubmib working group
  *> > >   *> mailing list ([email-masked]) since this is a WG work item.
  *> > >   *> 
  *> > >   *> Thanks
  *> > >   *> 
  *> > >   *> Mike
  *> > >   *> 
  *> > > 
  *> > 
  *> 

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

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 6 May 2002 13:14:21 -0700 (PDT)

> one); would it not still be a standard today, regardless of its current

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.

> THAT -- or, as the system is supposed to work, it is OBSOLETED by a

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

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 6 May 2002 13:14:21 -0700 (PDT)

Mike

---

From: "Andrew Smith" <[email-masked]>
Date: Tue, 7 May 2002 00:33:56 -0700

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-masked] [mailto:[email-masked]]On Behalf Of
C. M. Heard
Sent: Monday, May 06, 2002 1:14 PM
To: Hubmib Mailing List
Cc: Bob Braden; [email-masked]; [email-masked]
Subject: Re: [Hubmib] RE: Historic confusion over Ethernet MIBs!

Mike

---

From: "Andrew Smith" <[email-masked]>
Date: Tue, 7 May 2002 00:33:56 -0700

So, what to do about it?

Andrew Smith

-----Original Message-----

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 7 May 2002 01:06:01 -0700 (PDT)

> 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

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

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

> them contains the phrase "Obseletes RFC 1643".

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

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

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

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 7 May 2002 01:06:01 -0700 (PDT)

//cmh