[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Further discussion about IANA Considerations for MIBs
Mike... documents that do NOT require any IANA actions/work MUST ALSO
contain an IANA considerations section. In that case it should specify
that there are no actions required by IANA (or some such).
Not sure that is clear from your text below.
Thanks,
Bert
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: donderdag 3 juni 2004 22:19
> To: Michelle S. Cotton; Steve Conte; RFC Editor; Mreview (E-mail)
> Subject: RE: Further discussion about IANA Considerations for MIBs
>
>
> On Wed, 5 May 2004, Wijnen, Bert (Bert) wrote:
> > [added Mike, who is editor for MIB review guidelines]
> ...
> > > From: Michelle S. Cotton [mailto:cotton@icann.org]
> > > Sent: donderdag 29 april 2004 18:12
> > > To: Bert Wijnen (Bert); Steve Conte
> > > Subject: Further discussion about IANA Considerations for MIBs
> ...
> > > Steve and I both agree (Steve tell me if that is
> > > not correct), we think for the future, it is
> > > -really- helpful for there to be an IANA Considerations
> > > section stating exactly what we are to do.
> > > In the case of MIBs, it could be a removable
> > > section that says something like:
> > >
> > > *******************************************************
> > >
> > > IANA Considerations section:
> > >
> > > In section xx, the IANA is requested to assign a
> > > transmission number for xxxxx. Please remove this
> > > section upon publication of this document.
> > >
> > >
> > > *******************************************************
>
> Michelle, Steve, RFC Editor, and MIB Doctors:
>
> Bert suggested that it would probably be best to leave the IANA
> Considerations section in the final RFC in order to document the
> assignments that are made. Here are the changes to
> <draft-ietf-ops-mib-review-guidelines-02.txt> that I propose to
> make. Please let me know whether or not this will be satisfactory.
>
> In Section 3.7:
>
> OLD:
> Note that an IANA Considerations section is NOT required
> if the only
> IANA action needed is the assignment of the object
> identifier for the
> MIB module's MODULE-IDENTITY value. A note in the form of an ASN.1
> comment requesting such an assignment is sufficient for this; see
> Section 4.5 for an example.
>
> NEW:
> Note that an IANA Considerations section MUST also be
> present in any
> specification that requires the IANA to update an existing
> registry.
> Documents containing the initial version of a MIB module will
> generally require that the IANA assign an OBJECT
> IDENTIFIER value for
> the MIB module's MODULE-IDENTITY value (and possibly to make other
> assignments as well) and so will generally be subject to this
> requirement. The IANA Considerations section that requests such an
> assignment MUST specify the registries that are to be updated, the
> descriptors to which OBJECT IDENTIFIER values are being
> assigned, and
> the subtrees under which the values are to be allocated. The text
> SHOULD be crafted so that after publication it will serve
> to document
> the OBJECT IDENTIFIER assignment. Something along the following
> lines would be appropriate for a document containing a single MIB
> module with MODULE-IDENTITY descriptor xyzMIB that is to
> be assigned
> a value under the 'mib-2' subtree:
>
> The MIB module in this document uses the following IANA-assigned
> OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
>
> Descriptor OBJECT IDENTIFIER value
> ---------- -----------------------
>
> xyzMIB { mib-2 XXX }
>
> Editor's Note (to be removed prior to publication): the IANA is
> requested to assign a value for "XXX" under the 'mib-2'
> subtree and to record the assignment in the SMI Numbers
> registry.
> When the assignment has been made, the RFC Editor is asked to
> replace "XXX" (here and in the MIB module) with the assigned
> value and to remove this note.
>
> Note well: prior to official assignment by the IANA, a draft
> document MUST use placeholders (such as "XXX" above) rather than
> actual numbers. See Section 4.5 for an example of how this is done
> in a draft MIB module.
>
> In Appendix A:
>
> OLD:
> 7.) IANA Considerations Section -- if the draft contains
> the initial
> version of an IANA-maintained module, verify that the
> MODULE-IDENTITY
> invocation contains maintenance instructions that comply with RFC
> 2434. Note that the IANA Considerations section that will
> appear in
> the RFC MUST contain a pointer to the actual
> IANA-maintained module.
>
> NEW:
> 7.) IANA Considerations Section -- if the draft requires an OID
> value to be assigned, ensure that an IANA Considerations section is
> present and that it contains the required information. If
> the draft
> contains the initial version of an IANA-maintained module, verify
> that the MODULE-IDENTITY invocation contains maintenance
> instructions
> that comply with the requirements in RFC 2434. In the latted case
> the IANA Considerations section that will appear in the RFC MUST
> contain a pointer to the actual IANA-maintained module.
>
> Thanks,
>
> Mike Heard
>
>