Peter,
Thank you for submitting this draft. It clarifies some of the most
consistent sources of cyclic discussion that appear on the IETF discussion
list.
I have a couple of questions.
The most consistent source of cyclic discussion that I didn't see addressed,
is the use of RFC 2119 conformance terms in requirements drafts, and various
other flavors of non-standards-track drafts. The draft itself explicitly
targets standards-track documents.
My impression is that acceptable practice varies across the IETF, so (at
least when I was an active Gen-ART reviewer) this came up from time to time
in cross-area reviews. Is there anything the IESG can say about this, to
give guidance to the community?
Sections 2.3 and 2.4 leave the requirement to say why one might not
implement a SHOULD (and SHOULD NOT) as, well, a SHOULD. To ask the
meta-review question, is there a reason why explaining a SHOULD (and SHOULD
NOT) is a SHOULD, and not a MUST? :D
It's fine with me if the list of reasons isn't complete (so, "SHOULD" = "do
X unless you have a good reason; good reasons include Y, and there may be
other good reasons" would be implicit), but a bare SHOULD (or SHOULD NOT)
with no explanation doesn't seem helpful. I've been told by some working
groups "we think doing it is a MUST, but some deployed implementations don't
do it, so it's a SHOULD". If that's the reason, perhaps writing it down
would be healthy.
And I'd really like to see discussions of consequences as a MUST, even if
explaining a SHOULD (or SHOULD NOT) remains a SHOULD.
I hesitate to bring the last one up, but I also see drafts that use the
formulation "MUST do X unless Y". Would it be helpful to mention this? I
believe "MUST X unless Y" is the moral equivalent of a SHOULD - perhaps you
don't have to do anything except say that?
Thanks again for doing the work. Any cyclic discussion we can stop cycling
on, is a beautiful thing!
Spencer
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
