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@xxxxxxxxxxxxxx> 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@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf