[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Further discussion about IANA Considerations for MIBs
Michelle, Steve, RFC Editor, and MIB Doctors:
Based on your feedback, I have edited Section 3.7 and the related
checklist item 7 in Apendix A as shown below. If you see any
problems please let me know.
Mike Heard
3.7. IANA Considerations Section
In order to comply with IESG policy as set forth in
http://www.ietf.org/ID-Checklist.html, every Internet-Draft MUST
contain an IANA Considerations section. The requirements for this
section vary depending what actions are required of the IANA.
If an Internet-Draft defines a name space that is to be administered
by the IANA, then the rules in Section 4.7d of [RFC2223bis] apply.
That is, the document MUST include an IANA Considerations section
conforming to the guidelines set forth in [RFC2434] specifying how
that name space is to be administered, and that section MUST be
retained in the final published RFC.
Name spaces defined by MIB documents generally consist of the range
of values for some type (usually an enumerated INTEGER) defined by a
TEXTUAL-CONVENTION (TC) or of a set of administratively-defined
OBJECT IDENTIFIER (OID) values. In each case the definitions are
housed in stand-alone MIB modules that are maintained by the IANA.
These IANA-maintained MIB modules are separate from the MIB modules
defined in standards-track specifications so that new assignments can
be made without having to republish a standards-track RFC. Examples
of IANA-maintained MIB modules include the IANAifType-MIB
(http://www.iana.org/assignments/ianaiftype-mib), which defines a
name space used by the IF-MIB [RFC2863], and the IANA-RTPROTO-MIB
(http://www.iana.org/assignments/ianaiprouteprotocol-mib), which
defines a name space used by the IPMROUTE-STD-MIB [RFC2932].
The current practice for such cases is to include a detailed IANA
Considerations section complying with [RFC2434] in the DESCRIPTION
clause of the MODULE-IDENTITY invocation in each IANA-maintained MIB
module and for the IANA Considerations section of the MIB document
that defines the name spaces to refer to the URLs for the relevant
modules. See RFC 2932 [RFC2932] for an example. This creates a
chicken-and-egg problem for MIB documents that have not yet been
published as RFCs because the relevant IANA-maintained MIB modules
will not yet exist. The accepted way out of this dilemma is to
include the initial content of each IANA-maintained MIB module in a
non-normative section of the initial issue of the document that
defines the name space; for an example see [RFC1573], which
documents the initial version of the IANAifType-MIB. That material
is usually omitted from subsequent updates to the document since the
IANA-maintained modules are then available on-line (cf. [RFC2863]).
Reviewers of draft MIB documents to which these considerations apply
MUST check that the IANA Considerations section proposed for
publication in the RFC is present and contains pointers to the
appropriate IANA-maintained MIB modules. Reviewers of Internet
Drafts that contain the proposed initial content of IANA-maintained
MIB modules MUST also verify that the DESCRIPTION clauses of the
MODULE-IDENTITY invocations contain an IANA Considerations section
compliant with the guidelines in [RFC2434].
If an Internet-Draft requires the IANA to update an existing registry
prior to publication as an RFC, then the IANA Considerations section
in the draft MUST document that fact. Although [RFC2223bis] does not
require an IANA Considerations section in the final published RFC in
this case, recent practice has been to include an IANA Considerations
section that documents the assignments actually made. MIB documents
that contain 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. Internet-Drafts containing such MIB modules MUST contain an
IANA Considerations section that specifies 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 assignments. For
example, something along the following lines would be appropriate for
an Internet-Draft containing a single MIB module with MODULE-IDENTITY
descriptor powerEthernetMIB 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
---------- -----------------------
powerEthernetMIB { 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.
If an Internet-Draft makes no requests of the IANA, then that fact
MUST be documented in the IANA Considerations section. When an
Internet-Draft contains an update of a previously published MIB
module, it typically will not require any action on the part of the
IANA, but it may inherit an IANA Considerations section documenting
existing assignments from the RFC that contains the previous version
of the MIB module. In such cases the draft MUST contain a note
(which SHOULD be removed after publication) explicitly indicating
that nothing is required from the IANA. For example, a draft that
contains an updated version of the POWER-ETHERNET-MIB [RFC3621] might
include an IANA Considerations section like the following:
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
powerEthernetMIB { mib-2 105 }
Editor's Note (to be removed prior to publication): this draft
makes no additional requests of the IANA.
If an Internet-Draft makes no requests of the IANA and there are no
existing assignments to be documented, then there is no need for an
IANA Considerations section in the published RFC, and suitable text
for the draft would be something along the following lines:
This document makes no request of the IANA.
Note to RFC Editor: this section may be removed upon publication
as an RFC.
[ Skipping down to Appendix A: MIB Review Checklist ]
7.) IANA Considerations Section -- this section must always be
present. If the draft requires no action from the IANA, ensure that
this is explicitly noted. If the draft requires OID values to be
assigned, ensure that the IANA Considerations section contains the
information specified in Section 3.7 of these guidelines. 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
latter case the IANA Considerations section that will appear in the
RFC MUST contain a pointer to the actual IANA-maintained module.