[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Further discussion about IANA Considerations for MIBs
On Sat, 5 Jun 2004, Bob Braden wrote:
> A few comments on your text.
Thanks for taking the time to comment. It's very helpful.
> *> 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!
You are right. I will change the text to say that.
> 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.]
I have asked for guidance from Bert on this matter, and he is
consulting with the other IESG members . The terminology did seem
to fit our purposes, and it's used throughout the document in
the following sense:
MUST: something that is mandatory for an author to do in order to
get the document approved. A reviewer is not supposed to let
such things slide.
SHOULD: a guideline that an author had better have a good reason
for not following. A reviewer is expected to ask for an explanation
if the guideline is not followed.
and so on. But maybe this is not the right thing to do.
In any case, the next draft will comply with the guidance I get from
the IESG.
> *> 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).
Agreed. I'll change that part to read:
If an Internet-Draft defines a new name space that is to be
administered by the IANA, then the document MUST include an IANA
Considerations section conforming to the guidelines set forth in
RFC 2434 [RFC2434] that specifies how the name space is to be
administered.
modulo a possible adjustment to the MUST terminology.
> *> 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
> *> this case, recent practice has been to include an IANA Considerations
> *> section that documents the assignments actually made. MIB documents
>
> 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.
I agree, and I will implement your recommendation.
[ ... 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. [ ... ]
>
> Again, misdirected SHOULD. How about "will be"?
Agreed. I'll change the parenthetical phrase to read
"(to be removed prior to publication)".
...
> *> 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.
I do trust the RFC Editor. The intent is to make it clear to the authors
(and reviewers) what to expect. There have been proposals in recent days
(see ftp://ftp.ietf.org/ietf-mail-archive/wgchairs/) to put in something
like this:
This document creates no new requirements on IANA namespaces [RFC2434].
which would create extra work for the RFC Editor, namely stripping a
gratuitous reference along with the text. For a long time we have asked
people NOT to put citations to RFC 2026 in the I-D boilerplate because
the boilerplate will get stripped out and will leave the reference
dangling. I think that the same consideration applies here. The
suggested text is intended to make that clear.
Once again, thanks for taking the time to comment.
Mike Heard