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

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

Scott writes
> 
> my issue on having an IANA considerations section in MIBs was to
> give teh IANA instructions if someone sends in a request to extend
> the current MIB by adding a new value in a list of values (like
> adding a new network type when someone develops a 13.5MHz Ethernet)
> 
Well this example is about adding an ifType to a IANA maintained MIB
module that has already a description on how to do it (although recently
it has been proven that we need to be more specific, which is what
Michelle, KZM and I are working on.

If new such IANA maintaind namespaces or "types" or whatever get
defined, then YES they MUST have an IANA considerations section,
as per oru NITs web page.

> I think it it is useful to say how the MIB gets extended in the RFC so
> the IANA knows what to do & can point to specific directions on what
> to do (or not to do)
> 
RFC2578 does explain how MIB modules can be extended. The rules are
all there. And MIB modules will all go through MIB Doctor review, so
I think we have that under control. I also think that these rules are
too much to require Michelle to understand and check them all.

If a MIB defines a specific new namespace or a new (IANA maintained)
enumeration, then YES they MUST specify IANA considerations.
And such has been happening and our NITs page still states that that
must be done. 

My amendment is meant to make clear that if all that IANA needs to do
is to assign an OID, that that alone does not require a IANA 
Considerations Section.

Does that not make sense?

Bert
> Scott
>