RE: IANA considerations requirement in "AD Review of I-Ds" (http: //w ww.ietf.org/ID-nits.html)

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Thomas answers me:
> 
> > Nope, cause we're talking about MIB modules and/or SMI, not
> > about the protocol to transport the data.
> 
> Blush. 
> 
> > I do not see why RFC2578 (pages 36/37) is not good enough in
> > this respect.
> 
> These pages provide guidance for when a new OID needs to be assigned
> and when you can just change an existing one.
> 
> But thinking about this more, I'm not sure there really is an
> issue. We may well be way out in hypothetical land. :-) MIB OIDs
> assignments are different then most other name spaces. Let me give a
> hypothetical example. Suppose the foo mib recycles at proposed. A few
> new objects are added and a few are deprecated. The existing OID is
> just extended for the new definitions, right? Deprecated objects are
> still there but eventually just disappear from use.

Actaully, in such a case existing objects cannot be changed, except
within the rules as specified in rfc 2578. If semantic change to 
an object is needed, then you derprecate the current one and 
create a new object.

The deprecated object keeps the same OID, the new object gets a new
OID under the tree assigned to this specific MIB module.

Evenutually, the deprecated objects may change to obsoleted.
deprecated means - no new implementation required, but they may still 
                   be implemented for backward compatibility.
                   they are intended to be obsoleted in fiture
obsoleted means - no need to implement anymore. Still some old devices
                  could still have such objects, and a walk of the 
                  mib for such an old device would still show them

> Walking the tree, you might pick up all the objects still using
> the same OID (both new and deprecated).
> 
See abobe

> In protocol bar, there might be a field with IANA values. We might say
> future assignments require standards track, so not just anyone can
> extend the protocol.
> 
> But what about extending the foo MIB? Do we (or do we want to) say the
> foo mib can only be extended via a standards action? Not clear there
> is a need to do this in MIBs.
Well, if the foo MIB is in a stds track document, then we do have
a process defined on how to update/extend such a document, no?
If it is informational, then the process allows people or a WG
to pick it up and change it and submit it as a new informational
or as a stds track and we will evaluate accordingly. Also for
informational, we still do MIB review, or at least I have been 
making sure it happens when they show up on IESG agenda.

> And the de facto policy (as you mentioned) is standards track/ietf 
> consensus is necessary to get anything in the mib-2 space, so
> that is sort of the default policy and mib doctor review is
> being the sanity check.
>
Even informational or experimental MIB docs go through MIB review.
We may not be as strict on some things, but we are as strict on
basic MIB rules and OID assignments.
 
> I guess an individual document could request some special rules if it
> wanted, but the possibility has just not come up.
> 
Would be though to allow special rules that would conflict with
the base MIB/SMI rules. An individual (informational or experimental)
doc might get away with doing some things that we would rather see
done different, but not with breaking the rules that keep the
OID tree clean and the MIB structure/syntax clean.

> But I may also be totally confused at this point, so it might be
> easier to just drop the thread.. :-)
> 
Maybe the above helped a bit.

Bert
> Thomas
>