Bert,
I want to reinforce Dave's comments and perhaps carry them a bit
further. If the ID-checklist were just the general guidance
that I believe it started out to be, the distinctions I suggest
below would probably be unnecessary. But we've seen recently
that there are very few steps between having a list and having
everything on that list become rigid, mechanically-applied,
requirements.
--On Saturday, 09 August, 2008 09:20 -0700 Dave Crocker
<dhc2@xxxxxxxxxxxx> wrote:
> Bert, et al,
>
> Something that might help further discussions quite a bit is
> considering annotation and re-organization of the document, to
> clarify some basic distinctions.
>
> For example, labeling the bits that are based on IETF
> standards rules versus the bits that are based on IESG
> requirements? Equally, what pertains to documentation
> standards versus what pertains to technical/protocol issues?
Many of the bits that "pertain to documentation requirements"
are IESG interpretations of RFC Editor guidelines. The RFC
Editor has traditionally been much more flexible about their
rules than recent trends in the IESG have been. Even when the
rules come from the IESG, it would be useful to better
distinguish between firm requirements (e.g., the IPR
boilerplate) and guidance (e.g., things to which one should
either conform or expect to have to explain, convincingly, why
not).
> The document has evolved into a possibly disorganized mixture
> of these and last month's discussions was challenged to
> separate issues, I think.
>
> This kind of change would not be modification of the Checklist
> semantics, but would add clarity to what is currently there.
But it is precisely the semantics that I think are at issue.
This is less what is in the checklist because I believe we could
agree that everything there is at least good general guidance
than about the apparent tendency for entries in the checklist to
become rigid rules that will be enforced even if specific
circumstances suggest otherwise.
> Any serious effort to clarify the document in this way is
> likely to engender more focused discussion than was possibly
> earlier, if only by offering some specific and relevant
> categorical distinctions.
And, in the case of the distinctions I'm suggesting, permit
meaningful community consideration of whether there is consensus
about particular rules, which may be different from consensus
about general guidance.
regards,
john
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf