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

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

> > I do not think that my amendment does dimish the need for an IANA
> > COnsiderations section if extensions are to be administered by IANA.
> 
> we may be talking past each other I am not sure
> 
> I am worried about the case where the intention is to not
> have any extensions other than by revising the RFC - there should be
> an IANA Considerations section that says that the IANA is to make no
> registrations
> 
> i.e. I am focusing on your use of the term "if"
> 
> we have had too many cases of late where someone (often these
> days another standards organization) wants to extend an IETF
> protocol and assumes that the extension can just be registered
> with the IANA - I think we need to make it clear in many
> documents that the protocol (including MIB) can not be extened
> in that way - i.e. an individual can not add another branch to 
> an IETF MIB just by sending a registration request to the IANA
> 
I think IANA understands that very well, and I have not seen 
people do that. Some people will change MIB modules for their own
private use without telling anyone... I consider that a bug in
implementing. 
In any event, if you think this is needed, and if IANA agrees,
then we may need a separate document that makes such a statement.
But I am unaware of an existing problem here.

IANA knows that assignments under 
- mib-2 needs stds track or IETF consensus approval. 
- experimental, people can just ask (FCFS)
- enterprise tree... any enterprise can just ask (FCFS) and
  then they can define any MIB module they want, including
  copying one of our stds track MIB modules, reassign under
  their enterprise tree and make arbitrary changes. We do not
  like that... but I also do not see how we can control or
  discourage it any stringer than what is already known.

Bert
> 
> Scott
>