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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 6 May 2002 14:01:42 +0300

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

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 7 May 2002 11:37:42 +0300

Please see comments below. As the issues have a rather strong admin and 'political' content, I am not sure which hat I am wearing ;-)

> From: C. M. Heard [mailto:[email-masked]]
> Sent: Tuesday, May 07, 2002 11:06 AM
> To: Hubmib Mailing List; [email-masked]
> Subject: RE: [Hubmib] 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.)

I think it would be a good thing to add this table in the next version of the Internet-Draft.

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

Andy means (I think) adding the IEEE Standard version explicitly in the Module Compliance and REFERENCE clauses. This seems a good addition.

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

Indeed, but mentioning the version / edition of the IEEE document would solve this.

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

I would object to this. Actually the IEEE 802.3 people seem to be very happy with the IETF taking upon the SNMP MIBs work. They have little experience in SNMP, and prefer to take the protocol agnostic approach again nowadays.

There are other good reasons for taking this work to the IETF beyond SNMP expertise:
- The new horizons that Ethernet is crossing get closer tot he providers space (metro transport, WAN, residential subscribers), and there is little experience in the IEEE about how these application spaces are managed. 
- The WIS MIB has specific 'cross-technology' issues with the SONET MIB, and this may happen in the future with EFM-copper for example
- In many cases the Ethernet MIBs added new objects beyond the direct reflection of the GDMO HW-related objects. Implementations seem to prove that at least some of these additions were considered valuable and adopted.

I would also note that some customers were confused by the IEEE issuing SNMP MIBs, as it was done for 802.1X and 802.3ad. Beyond the root OID issue, some big customers miss the IETF process of progressing the standards status. As you are probably aware the Bridge MIB WG is currently 'translating' the 802.1X MIB to the IETF space.

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

I am personally confused because I think that I am hearing conflicting messages from the IESG. I am not interested in entering a philosophical discussion about what 'Historical' means. Our purpose as a Working Group is to encourage customers to adopt the more recent versions of the MIB because they cover the new Ethernet technology extensions, and to use SMIv2 and SNMPv3, reflecting the progress of the SNMP technology. The scope of the current discussion is to find the best way to do it.

> //cmh

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 7 May 2002 11:37:42 +0300

Regards,

Dan