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

[Thomas Narten <narten@us.ibm.com>]

> 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. Walking the tree,
you might pick up all the objects still using the same OID (both new
and deprecated).

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. 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.

I guess an individual document could request some special rules if it
wanted, but the possibility has just not come up.

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

Thomas