Brian,
We agree about the desirability of making sure than some things
are explicitly documented and explicitly part of what gets
reviewed. But I continue to believe, as I have believed for
years, that adding more and more mandatory material to RFCs or
I-Ds is not the best solution to that particular problem.
Perhaps, in line with the PROTO effort (and maybe the ISD
discussion), it is time to revisit the other approach: rather
than cluttering up I-Ds with materials that can be filled out
pro-forma and that the RFC Editor may then remove (or not),
migrate at least some of these procedural requirements
associated with protocol specifications from the I-D to a
"submission checklist" that a WG or individual would provide to
the IESG as part of the request for Last Call and approval
action. That document could contain, e.g., an explicit
statement as to whether the WG had examined IANA issues and
decided that there were none, rather than just providing pro
forma text or boilerplate, as well as draft protocol action
statements, etc. The IESG gets more information, in clearer
form, and we don't end up with a choice between information
getting lost and more clutter in RFCs.
Of course, if one were doing ISDs, that text and anything else
that relates to the process and context for approving a
standard, rather than information key to the protocol
specification itself, could, when the spec was approved, be
reasonably be transposed into the ISD.
john
--On Thursday, 09 June, 2005 11:06 +0200 Brian E Carpenter
<brc(_at_)zurich(_dot_)ibm(_dot_)com> wrote:
Ned Freed wrote:
...
The IETF Internet-Drafts page notes that "All
Internet-Drafts that are submitted to the IESG for
consideration as RFCs must conform to the requirements
specified in the I-D Checklist". The current version of the
ID-Checklist clearly states:
That's most unfortunate. What do we need to do to get this
silly and counterproductive requirement removed?
Enough context has been removed that I don't know quite what
you're
objecting to, but the intent of the I-D checklist is to avoid
the IESG having to kick back documents for trivia, so you can
argue about what should or shouldn't be in the checklist, but
you surely can't argue against it being used for its intended
purpose.
I believe the requirements exist to ensure that draft
authors give due consideration to IANA Considerations and
that IANA can readily determine if some action is or is not
required.
There is another purpose IMHO: ensure that future readers
(implementers
and deployers of the technology) know whether they need to
deal with
any IANA registration issues. For this reason, I have a
strongly held
opinion that null IANA Considerations sections should *not* be
removed.
The problem is that requiring such a section creates no such
assurance. I've seen any number of documents with IANA
considerations that initially failed to list all the
considerations.
Yes indeed, and I see a lot of IESG DISCUSSes on exactly this
point.
And given past experience with "security
considerations: none" sections, there is no reason to believe
that requiring such a section will actually result in IANA
considerations being properly called out. In fact I'd say
there's a good chance it will cause obscure considerations to
be missed.
I think experience shows otherwise: the fact that reviewers,
including the
IESG, are paying increasing attention to this section is in
fact catching
omissions.
Like it or not, boilerplate is not now and never will be a
useful subsitute for careful review.
I agree
And as the pile of useless crap we require gets ever-larger it
gets harder, not easier, to get that review.
I disagree. Actually, the mandatory presence of this section
*triggers*
review (see above comment).
Evidently (and unfortunately) the
IETF Secretariat apparently doesn't enforce that part of the
ID-Checklist rules.
The ID-Nits tool checks it and the future automated submission
tool will
check a lot more than the Secretariat can do manually.
Brian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf