Re: [IETFMIBS] Moving a MIB forward

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

On Mon, 5 Jan 2009, Jeffrey Haas wrote:
> On Sun, Jan 04, 2009 at 02:18:06PM -0800, C. M. Heard wrote:
> > [RFC 4181 Section 4.3 says:]
> >    [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.
> 
> 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.

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
_______________________________________________
IETFMIBS mailing list
IETFMIBS at ietf.org
https://www.ietf.org/mailman/listinfo/ietfmibs