Subject: [IETFMIBS] Moving a MIB forward

From: Jeffrey Haas <[email-masked]>
Date: Fri, 2 Jan 2009 11:09:30 -0500

I'm about a day from issuing the last edits for the BGP MIB version 2.
Given the structural instability this MIB has had over the course of its
development it doesn't have a wide base of implementation.  IDR policy
before a draft is requested to move to RFC status is that it has at
least two interoperable implementations.  However, prior to an
implementation being done, we'll require two registrations under mib-2:
one for the TC MIB, one for base MIB.

As best as I am able to tell, mib-2 assignments are done only at RFC
publication time.

We would seem to have a chicken and egg problem.

One likely solution to this chicken and egg issue would be getting a
registration point under experimental.  However, RFC 4181 sec. 4.3 makes
it clear that this is not a good idea and probably would not be allowed.

I'm hoping for some guidance as to what should be done in this situation
prior to issuing the updates to the I-Ds.  Is there an equivalent to the
"early registration" policies that are seen for other protocol
registries?

-- Jeff
_______________________________________________
IETFMIBS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietfmibs

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 2 Jan 2009 10:28:30 -0800 (PST)

On Fri, 2 Jan 2009, Jeffrey Haas wrote:
> I'm about a day from issuing the last edits for the BGP MIB 
> version 2. Given the structural instability this MIB has had over 
> the course of its development it doesn't have a wide base of 
> implementation.  IDR policy before a draft is requested to move to 
> RFC status is that it has at least two interoperable 
> implementations.  However, prior to an implementation being done, 
> we'll require two registrations under mib-2: one for the TC MIB, 
> one for base MIB.

The purpose of this policy, as I understand it, is to make sure that 
stuff does not get deployed on a wide scale (which often does happen 
with Proposed Standards) until there is implementation experience.  
So, the pre-standard implementations of these MIB modules would 
presumably be targeted ONLY for limited experimentation, not for 
widespread operational deployment.

[As an aside -- I didn't know that the policy applied to MIB 
modules; I thought it was only for routing protocols, because of 
the possibility of major disruption.  But I digress.]

> As best as I am able to tell, mib-2 assignments are done only at RFC

That is normally the case.  But exceptions can be made with IESG 
consent.

> One likely solution to this chicken and egg issue would be getting 
> a registration point under experimental.  However, RFC 4181 sec. 
> 4.3 makes it clear that this is not a good idea and probably would 
> not be allowed.

That isn't what the document says, or at least not what it was 
intended to say (as document editor, I think I can speak with some 
authority regarding the intent :)

The experimental subtree is an appropriate place to do an initial 
pre-RFC registration for __experimental__ purposes.  In the present 
case, you could publish a draft with assignments under the 
experimental subtree, make two implementations from the draft, and 
verify interoperability as outlined in RFC 2438.  HOWEVER, it would 
be INAPPROPRIATE to deploy these pre-standard implementations in an 
operational environment.  As the document says:

   Experience has shown that it is impractical to move objects from 
   one subtree to another once those objects have seen large-scale 
   use in an operational environment.  Hence any object that is 
   targeted for deployment in an operational environment MUST NOT be 
   registered under the experimental subtree, irrespective of the 
   standardization status of that object.  The experimental subtree 
   should be used only for objects that are intended for limited 
   experimental deployment.  Such objects typically are defined in 
   Experimental RFCs.

This text was put into the review guidelines because of a specific 
case that arose in 2002.  See the attached e-mail message for 
further information.

Now, __if__ you are expecting the initial MIB module implementations 
to be deployed in an operational environment, __then__ the 
experimental subtree should definitely be avoided, and the mgmt 
subtree should be used instead.  But in that case, you should 
__publish__ the MIB modules and plan to observe SMIv2 change control 
rules.  If IDR policy requires that the MIB modules not enter the 
standards track until they has been implemented, they could be 
published in an experimental RFC with mib-2 regustrations.  If you 
succeed in getting two interoperable implementations, then the 
specification could be republished as a Proposed Standard (observing 
SMIv2 revision rules if there are any changes).  Frankly, it's not 
clear to me why this would be better than issuing a Proposed 
Standard from the get-go, but the Experimental option is open if you 
want to pursue it.

> I'm hoping for some guidance as to what should be done in this 
> situation prior to issuing the updates to the I-Ds.  Is there an 
> equivalent to the "early registration" policies that are seen for 
> other protocol registries?

I don't remember a case, but I see no reason why it could not be 
done, provided that the IESG approved.  I would expect, however, 
that the IESG would approve such a registration only after the 
specification itself received approval and was in the publication 
queue, since the policy for the mib-2 branch is (according to the 
IANA web site) "REF Required".

Mike

Subject: RE: What to do when moving from experimental to PS
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "C. M. Heard" <[email-masked]>, "Mreview (E-mail)" <[email-masked]>
Date: Sun, 17 Nov 2002 17:58:14 +0100

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:[email-masked]]
> 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
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Jan 2009 20:11:11 +0100

> it clear that this is not a good idea and probably would not be allowed.

If this routing area rule is just about gaining implementation
experience, then nothing is really needed since people can root it
wherever they want during implementation time. You need to settle on a
common registration point once you look for interoperability outside a
lab.

That said, it is also unclear to me whether rules likely made for new
routing protocols really apply to management interfaces. But that is
something the ADs can discuss and sort out.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
IETFMIBS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietfmibs

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 4 Jan 2009 09:54:20 +0100

You can check interoperability of implementations without rooting your
MIB modules under mib-2 at this stage. You can use any private
enterprise space under the root of one of the vendors who are involved
for this purpose, or you can ask for a private enterprise number for idr
(but make sure it's clearly documented as a private space for testing
interoperability). An experimental number is less advisable for the
reasons explained in RFC4181. 

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jeffrey Haas
> Sent: Friday, January 02, 2009 6:10 PM
> To: [email-masked]
> Subject: [IETFMIBS] Moving a MIB forward
> 
> Given the structural instability this MIB has had over the 
> course of its development it doesn't have a wide base of 
> implementation.  IDR policy before a draft is requested to 
> move to RFC status is that it has at least two interoperable 
> implementations.  However, prior to an implementation being 
> done, we'll require two registrations under mib-2:
> As best as I am able to tell, mib-2 assignments are done only 
> at RFC publication time.
> 
> One likely solution to this chicken and egg issue would be 
> getting a registration point under experimental.  However, 
> RFC 4181 sec. 4.3 makes it clear that this is not a good idea 
> and probably would not be allowed.
> 
> I'm hoping for some guidance as to what should be done in 
> this situation prior to issuing the updates to the I-Ds.  Is 
> there an equivalent to the "early registration" policies that 
> are seen for other protocol registries?
> 
> -- Jeff

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 4 Jan 2009 14:18:06 -0800 (PST)

> reasons explained in RFC4181.

Hmm, I wrote that part of RFC4181, and as far as I can see, it 
doesn't say that there is anything wrong with using an experimental 
number for __experimental__ purposes.  What it does says is:

   [A]ny object that is targeted for deployment in an operational 
   environment MUST NOT be registered under the experimental 
   subtree, irrespective of the standardization status of that 
   object.

>From this perspective, there is no difference between a private 
enterprise number assigned to idr for experimental purposes and an 
experimental number assigned to idr.  Either one is OK for use in 
the lab, and neither one is appropriate for operational deployment.

Mike

---

From: Bill Fenner <[email-masked]>
Date: Sun, 4 Jan 2009 18:09:30 -0800

> reasons explained in RFC4181.

You can also use  
enterprises.fenner(6316).inadvisable(42).bgp4V2(503958504) and  
enterprises.fenner(6316).inadvisable(42).bgp4V2TC(1986622039) instead  
of getting new numbers, if you want a private OID for implementation.

I do these inadvisable assignments for OID browsing of MIBs that don't  
yet have real assignments but they're also available for  
implementation, I guess.

   Bill

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 5 Jan 2009 10:16:43 +0100

Sure. My recommendation was based on the fact that I do not have
information that says that the interoperability testing happens in
strictly isolated labs conditions. 

Dan

> Sent: Monday, January 05, 2009 12:18 AM
> To: Romascanu, Dan (Dan); Jeffrey Haas
> Cc: IETFMIBS
> Subject: Re: [IETFMIBS] Moving a MIB forward
> 
> > for this purpose, or you can ask for a private enterprise 
> number for 
> > idr (but make sure it's clearly documented as a private space for 
> > testing interoperability). An experimental number is less advisable 
> > for the reasons explained in RFC4181.
> 
> Hmm, I wrote that part of RFC4181, and as far as I can see, 
> it doesn't say that there is anything wrong with using an 
> experimental number for __experimental__ purposes.  What it 
> does says is:
> 
> From this perspective, there is no difference between a 
> private enterprise number assigned to idr for experimental 
> purposes and an experimental number assigned to idr.  Either 
> one is OK for use in the lab, and neither one is appropriate 
> for operational deployment.
> 
> Mike
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 5 Jan 2009 09:18:15 -0500

Thank you all for your responses.  A bulk reply follows.

> the possibility of major disruption.  But I digress.]

I had made a generalization.  Perhaps it's an inappropriate one.  I'll
consult the chairs and the ADs.

> common registration point once you look for interoperability outside a

If that's generally considered acceptable for comparison purposes
(different prefix OIDs) when doing interop testing, I'm good with this
approach.

> the lab, and neither one is appropriate for operational deployment.

This is a consideration that's part of the motivation for my question.
I have an implementation written in Quagga that I'd like to send off to
them sometime shortly.  For my own testing purposes I have rooted my
implementation in my employer's experimental subtree.  Since Quagga is
an open-source project this would provide an implementation for
interoperability testing purposes hoever it would also expose a MIB
targeted for wide deployment outside of the intended mib-2 space.

If this code was released to the project, there's the likelihood that
it'll be accessed by some number of operators at the temporary OID
prefix for some time until they upgrade.  This is my motivation for
asking about early assignment.

-- Jeff

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 5 Jan 2009 07:09:27 -0800 (PST)

On Mon, 5 Jan 2009, Jeffrey Haas wrote:
> > [RFC 4181 Section 4.3 says:]

I think that you are reading the words "targeted for deployment in 
an operational environment" in a way that we did not intend.

The history behind the passage quoted above was this:  a MIB module, 
rooted in the experimental subtree, was published in RFC 2786.  
That specification was then adopted by the cable modem industry as 
mandatory-to-implement and put into a lot of deployed hardware.  
Later there was a request to put the specification on the standards 
track, and of course it was then desirable to re-root the MIB 
objects under mib-2.  But because the MIB module was already in wide 
operational deployment, it was not feasible to do so.

Your making an early implementation rooted under your employer's 
experimental subtree available for interoperability tests would not 
(or at least should not) be the same situation.  It would 
(presumably) be clearly understood that the experimental 
implementation is intended only for limited deployment in 
well-controlled environments and will have to be replaced when the 
MIB module moves to the standards track.  That's a far cry from a 
vendor consortium writing an experimental spec into its "mandatory 
to implement" list, and I don't see anything wrong with it.  Having 
a few operators using the temporary OID for some time until they 
upgrade is not a problem, since it doesn't foreclose the eventual 
upgrade path.  That is what RFC 4181 Section 4.3 was concerned with.

By contrast, getting an early mib-2 assignment and using that for a 
testing a draft which is still not stable is something that I, at 
least, would find objectionable.  Once you deploy stuff under the 
OID that is targeted for wide deployment, you will need to follow 
all the SMIv2 change control rules in order to avoid possible 
interoperability problems.  Once you have that requirement I would 
say you need to have a published, stable spec.

I hope that I've clarified (rather than muddled) the intent of 
RFC 4181 Section 4.3.

Regrds,

Mike Heard