Bert Wijnen wrote:
I believe that the ID-Checklist also helped Henrik write the
id-nits tool that will do a check for most of the checlist
items that can (reasonably) be checked by software
[...]
FWIW I consider your checklist as very helpful especially for
new authors, for all the reasons you have stated.
That things can get interesting when authors feel the need to
explore exceptions from a SHOULD is as it is, your checklist
can't go into all possible details. The 2821bis case was one
of those interesting things, we could talk about it for hours,
but this doesn't belong into the checklist.
New authors hopefully know that not following a SHOULD needs
a good excuse, and other authors certainly know it, but might
still disagree about some details of "good enough" excuses.
RFCs that will be so popular that everybody and his dog will
take their clues from these RFCs and not a relatively obscure
IETF-internal checklist are rare.
I've proposed to add RFC 5137, but if you or Russ think that
this is no good idea it is no problem. John proposed some
tweaks, I hope you'll look at his proposals.
I believe it has served its purpose very well.
Yes. Of course it's overwhelming what potential authors will
find when they look for advice, but again I think that is as
it is, there can't be one authoritative rule saying it all...
For starters folks here would disagree about the "authority".
And it won't suprise anybody here when I admit that one major
point in the 2606bis drafts is to confirm RFC 2606 as it was,
a recommendation wrt examples. Not more and not less.
FWIW I could even provide an example where not following this
recommendation triggered a DISCUSS, later solved by a "good
excuse". I'd not support to twist this 2606 recommendation
into mustard.
Frank
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf