RE: What to do when moving from experimental to PS

["C. M. Heard" <heard@pobox.com>]

Colleagues,

After re-reading <draft-ietf-ops-rfc2786std-00.txt> and the current
e-mail thread, it became apparent to me that the request to put
RFC 2786 onto the standards track did not originate from the author
from the users of the technology (as I had originally assumed) but
rather originated from the IESG.

Quoting from the abstract of draft-ietf-ops-rfc2786std-00.txt:

   The author is submitting this draft at the request of the O&M area
   director.  This memo revises and updates RFC 2786 [19] with the goal
   of moving the described protocol and MIB from Experimental to
   Standards Track.

and from Bert's e-mail:

>>>>> On Fri, 25 Oct 2002, Wijnen, Bert (Bert) wrote:
BW> The reason I want it on the standards track is because the security ADs
BW> and many others tell me that this is very usefull technology. 

In light of this, I'm inclined to take a different view than before on the
question of changing the root OID of the MIB.

Evidently, the MIB module in RFC 2786 has already been adopted as
de-facto standards by the cable modem industry and is already
deployed in a substantial installed base:

BW> The cable-modem industry has this MIB as "mandatory to implement" if
BW> the  cable modems want to be certified, so there is very wide 
BW> implementation and deployment in their industry.

If I were a large-scale uset of cable modems, I would not think
it worthwhile to disrupt my installed base to swap out a perfectly
adequate experimental MIB module for a functionally equivalent
standards-track MIB.  Instead, I would continue to require that
my suppliers implement the experimental MIB, and I would ignore
the standards-track replacement.

>>>>> On Fri, 25 Oct 2002, Andy Bierman said:
AB> I am divided on this issue.  On the one hand, there is the notion
AB> of doing the right thing wrt/ standards. On the other is the
AB> pragmatic concern of breaking existing implementations just to
AB> move the MIB root.  The reality is that some vendors will have
AB> to support the MIB in both MIB roots for a number of years if
AB> the root is moved now.  Is this better or worse than the possible
AB> confusion of a standards track MIB rooted under 'experiment'?

In the realm where the experimental MIB already enjoys wide deployment
the reality is likely to be that the new standards-track MIB root under
mib-2 will be ignored by users whether it is supported by implementors
or not.  Users are very reluctant to change something that works and
that has been widely deployed just to conform to a standard that offers
no functional advantage.

There are many historical analogies;  let me name just one.  In the
mid-1980s, long after the Ethernet "type" field defined in the DIX
Ethernet Blue Book had become entrenched, the IEEE decided to
standardize a "length" field in its place and to add an LLC header.
The standardized equivalent to the old "type" encapsulation was the
LLC/SNAP encapsulation.  Although it enjoyed the blessing of a standards
body, it offered no functional advantages over what it was intended
to replace, and indeed never succeeded in displacing the "type"
encapsulation where the latter had become entrenched (although it did
get used in other realms).  The IEEE eventually surrendered to this
reality and added the "type" field to the 802.3 Ethernet standard.

Realistically, I think we should expect a similar same fate for
a version of the SNMP-USM-DH-OBJECTS-MIB that is re-rooted from
{ experiental 101 } to some place under mib-2.  That, I think,
would cause even worse confusion than standardizing a MIB under
the experimental tree.

>>>>> On Thu, 24 Oct 2002, Juergen Schoenwaelder wrote:
JS> I support to move the top-level registration.
JS> 
JS> How many deployed implementations of this MIB are there? How many do
JS> we expect in 3 years? If the later number is significantly larger than
JS> the first one, we should just do the right thing. (And if the later
JS> number is not significantly larger, then there is probably not much
JS> value to put this on the standards track in the first place.)

>>>>> On Fri, 25 Oct 2002, Wijnen, Bert (Bert) replied:
BW> Difficult to say if people will actually use it 3 years from now.
[ ... ]
BW> The reason I want it on the standards track is because the security ADs
BW> and many others tell me that this is very usefull technology. 
BW> So one would expect people will adopt it and implement... but who are
BW> we to predict the future.

If cable modems continue to enjoy widespread popularity, and this MIB
is indeed useful in its present form, the cable modem industry will
probably continue to use it.  That may well be enough to ensure that
there will be more implementations in three years than now.  However,
because there is already a large deployed base, we cannot expect
cable modem service providers -- who are the users of the technology
-- to bother adopting a re-rooted but functionally equivalent MIB if
vendor implementations offer both.  In other words, what's out there
now will very probably remain the de-facto standard, at least in
the cable modem realm.

It's a good question, under the circumstances, whether it's necessary
to put the technology on the standards track.

>>>>> On Fri, 25 Oct 2002, Andy Bierman said:
AB> There should be a high-level policy that MIBs granted a root
AB> assignment under experimental can never be on the standards
AB> track unless they are re-rooted.  Was that policy known to the
AB> WG when the initial submission was assigned a root?  If not,
AB> then they have a case for not moving the root.

I think there already is such a policy, and it is spelled out in
RFC 2578 Section 4, "Naming Hierarchy":

   The experimental(3) subtree is used to identify objects being
   designed by working groups of the IETF.  If an information module
   produced by a working group becomes a "standard" information module,
   then at the very beginning of its entry onto the Internet standards
   track, the objects are moved under the mgmt(2) subtree.

Certainly the author of the RFC (it was an individual submission)
was responsible to know that.

Moreover, there is an explicit warning in the IESG Note on RFC 2786
of possible incompatible changes:

   This document specifies an experimental MIB. Readers, implementers
   and users of this MIB should be aware that in the future the IETF may
   charter an IETF Working Group to develop a standards track MIB to
   address the same problem space that this MIB addresses.  It is quite
   possible that an incompatible standards track MIB may result from
   that effort.

However, I think that the existence of a significant deployed base
trumps these considerations.

The purpose of having standards is to get people use them.  I think
that if the IESG wishes to go ahead and move this document onto the
standards track, then the best course would be to grant a waiver
to the provisions of RFC 2578 Section 4 and allow the MIB to remain
registered under the experimental subtree.  I don't think this should
be made into official policy, so it might be good to have some text
in the the RFC (possibly an IESG Note) explaining why this waiver was
granted and that it is not to be interpreted as a general policy.

In the future, we should restrict registrations under the experimental
subtree to just what RFC 2578 Section 4 says it's for, namely to
identify objects _that are being designed by working groups of the
IETF_.  Anything that is clearly intended for wide deployment or that
is being developed outside an IETF working group (as was indeed the
case for SNMP-USM-DH-OBJECTS-MIB) should be registered elsewhere (for
example, under the enterprise OID assigned to an industry consortium).

Mike