RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2

IPCDN folks,

After review of the WG input and comments on the email thread started on
1/5/2005 on the IPCDN mailing list, the WG chairs have come to the decision
to request a change of the OID MIB root for the IPCDN QoS MIB Internet-Draft
from ..mib-2(1) transmission(10) docsIfMib(127) to ..mib-2(1). If you have
any further comments on this matter, or wish to object to the decision,
please feel free to contact one or both of the WG chairs, or feel free to
escalate to our WG AD Bert Wijnen.

The proposed alternative was to keep the QoS MIB module under docsIfMIB, and
per the explicit request of the AD, to write an RFC3737-like document to
define IANA guidelines for registering MIB modules under the docsIfMIB
branch. 

The WG chairs have reviewed all the comments expressed publicly to the list.
We would like to add the following notes:

- Some of the technical comments made in favor of maintaining the OID root
do not take into account the fact that the IETF IPCDN Internet-Drafts have
evolved and that the MIB modules have changed drastically in the many
revisions, from object syntax changes to table entry OID renumbering, to
object deletions (not obsolescence), etc.

- The backward compatibility issues raised between the final IETF IDs to be
RFC'ed and the original IPCDN submissions are not caused strictly by the
IETF. The IETF supports backward compatibility between published versions of
RFCs (e.g. between RFC2669 and the to-be-published version of Cable Modem
Device MIBv2, RFC2669bis; between RFC2670 and the to-be-published version of
RF MIBv2, RFC2670bis), per the IETF documented guidelines of the procedures
to follow when updating IETF RFC MIB modules.

The IETF does NOT support backward compatibility between Internet-Draft
versions of MIBs, or between an Internet-Draft version and an RFC version,
because an Internet-Draft is not a stable reference. Note the following
relevant statement that is required to be included in every Internet-Draft
submitted to the IETF:

>Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite them
other than as "work in progress."

With respect to the rest of the IPCDN Internet-Drafts (i.e. other than the
updates to RFC2669 and RFC2670), the backward compatibility problem lies in
the fact that some Internet-Drafts have been implemented in products and the
associated MIB module implementations rooted under an IANA-controlled MIB
tree, wrongfully assigned outside the IANA jurisdiction.

The consequences of this backward compatibility problem must be addressed by
specific CableLabs product requirements in a CableLabs specification forum
-- not in the IETF.

- The change of a MIB module OID root (and MIB module identity names) was
previously done for the IPCDN BPI+ MIB in February 2003. This is documented
in the IPCDN meeting notes, see
<http://www.ietf.org/proceedings/03mar/slides/ipcdn-1/index.html
<http://www.ietf.org/proceedings/03mar/slides/ipcdn-1/index.html> >. The MIB
module OID root for the Subscriber Management MIB was changed in November
2002; see <http://www1.ietf.org/mail-archive/web/ipcdn/current/msg00333.html
<http://www1.ietf.org/mail-archive/web/ipcdn/current/msg00333.html> > and
<http://www1.ietf.org/mail-archive/web/ipcdn/current/msg00367.html
<http://www1.ietf.org/mail-archive/web/ipcdn/current/msg00367.html> >.

- Maintaining the QoS MIB and other MIB modules under docsIfMib may cause
some serious interoperability problems due to the illegal (i.e. non-IETF
sanctioned) OID assignments and implementations mentioned above.

- Writing an RFC3737-like document would delay the publication of the QoS
MIB which we do not feel justified based on the WG input and comments.

--- Rich Woundy and Jean-Francois Mule
    IPCDN co-chairs