[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: What to do when moving from experimental to PS
I don't think I have seen anyone react to Mike's change of position
here... which I think is based on evaluation of the real world.
I am kind of inclined to go with this view, but let them add a
clear statement that IESG allowed this based on (proven?) wide
implementation and deployment. So that future experiemental MIBs
can not easily claim precedent.
I'll first check with IPCDN WG to see if the wide implementation
deployment can be supported with documented information.
Does this make sense?
Thanks,
Bert
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: zaterdag 26 oktober 2002 22:21
> To: Mreview (E-mail)
> Subject: RE: What to do when moving from experimental to PS
>
>
> 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
>
>