[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Further discussion about IANA Considerations for MIBs
Bob, I agree that we may need to re-evaluate a number of uses of MUST/SHOULD
language.
But I DO think it is OK to use RFC2119 language in a document that we target
for BCP. So we cannot generically say that we shoul not use that language.
I am checking with IESG if I am correct in this (I think I am, but...
I have been wrong before for other things... )
Thanks,
Bert
> -----Original Message-----
> From: Bob Braden [mailto:braden@ISI.EDU]
> Sent: zaterdag 5 juni 2004 21:34
> To: cotton@icann.org; conte@icann.org; rfc-editor@rfc-editor.org;
> mreview@ops.ietf.org; heard@pobox.com
> Subject: 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
>