![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.