[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Further discussion about IANA Considerations for MIBs
Mike,
A few comments on your text.
*>
*> 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
You need to be careful in your wording here. I don't think you mean
EVERY Internet Draft. Internet Drafts cover a wide range, from very
rough, preliminary documents ("drafts", after all) to finished
documents that are going to be submitted to the IESG. Really,
IDChecklist strictly applies ONLY to the latter, I believe. It would
be a mistake for the IESG to try to be too anal about ALL Internet
Drafts!
Also, using a capitalized MUST here seems to me to be abusing the
MUST/MAY/SHOULD notation, which is defined for applicability of
technical specifications, not administrative policies of the IETF.
[I am sensitive about this, because I myself invented the MUST/SHOULD/MAY
terminology for RFC 1122, 1123, and I hate to see it used in unnatural
acts.]
*> 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.
Not exactly. Section 4.7d is empty, containing only a ptr to Section 2.10
and a ref to RFC 2434. Section 2.10 basically does nothing more than
point to RFC 2434. So I suggest collapsing these two sentences into:
If an Internet-Draft defines a name space that is to be administered
new/
*> by the IANA, 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.
*>
Whoa. Who are you saying MUST to?? This document is directed at authors,
who have no control over this. The most you can say is "will be"
(which is true).
*> 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
Another misplaced MUST, IMHO. How about "will"?
*> 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
Ditto.
*> 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
only/
*> 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
I think there has been general agreement that RFC2223bis will be
updated to add this "requirement"/RFC Editor policy. But this issue,
what stays/goes in the final published RFC, does not seem relevant to
the ID-Checklist document? I recommend omitting it.
*> 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
Another misbegotten MUST...
*> 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
ditto
*> 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
Again, misdirected SHOULD. How about "will be"?
*> 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.
*>
You don't really need to go to this lengths. The RFC Editor can be trusted
to remove empty IANA Consideration sections. We already do.
*> [ 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.
*>
Bob Braden