How to proceed with "Request to Move RFC 1643 to Historic Status"?
"C. M. Heard" <[email protected]>
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
Colleagues, Some time ago John Flick and I submitted the draft <draft-ietf-hubmib-1643-to-historic-00.txt>, entitled "Request to Move RFC 1643 to Historic Status", for working group review. The discussion that took place was inconclusive -- some thought that moving the spec to Historic was appropriate, while others (notably Bob Braden and Andrew Smith) advocated leaving it at Standard but writing an Applicability Statement that specifies the (limited) situations to which it applies. So let me ask: what do you think? Is requesting historic status for 1643 the right way to go, or should we instead write an Applicability Statement saying that 1643 should not be used for new implementations, but may continue to be used for already-deployed interfaces that support 10 Mb/sec half-duplex mode only? Or is some other alternative preferred? Two points to consider: - a half-duplex 10 Mbps interface that supports all the required objects in RFC 1643 _will_ conform to dot3Compliance2 in the current EtherLike-MIB in <draft-ietf-hubmib-etherif-mib-v3-02.txt> (and will in addition implement the deprecated object dot3StatsEtherChipSet, which is no longer required); - however, such an implementation _may fail_ to support the mauModIfCompl3 compliance statement of the MAU-MIB in <draft-ietf-hubmib-mau-mib-v3-02.txt>, since the requirement to do so postdates RFC 1643 (the requirement was levied because failure to implement the MAU-MIB leaves applications with no standard way to determine the media type in use, and no standard way to control duplex status, if such control is supported). Your feedback would be most helpful in deciding how to move forward on this. Regards, Mike