John and Dave,
I think that both of you (and some others) arwe looking at the ID_Checklist
too much as if it is part of our (rigid) process. Our processes aredescribed
in formally approved BCP documents.
The ID-Checklist is intended (or at least that is how it started, and as far
as I am concerned that is still the intention) to help in a few areas:
- Make document authors/editors and WG chairs (and reviewers) aware
of the many little things we found as ADs and IESG when reviewing
documents that came out of WGs. Those mistakes always later caused
confusion and delay in the further process.
- Reduce the document-time of AD, IESG, IETF LC-reviewers, RFC-Editor by
reducing extra steps to fix little and simple things.
- All those simple things were (and still are) documented in other RFCs or
in the RFC-Editor Style manual, and so it is/was not a new set of
rules or requirements
- Authors/Editors SHOULD know all these little things, but they often
did/do not know exactly what they are or where to find them.
The ID_Checklist is intended to help find these things.
- By documenting these things, it became easier/quicker to point to them
(both if found at AD or IESG review and earlier)
- By documenting them, the WG-Chair (document shepherd) can do a lot
of these checks, so that they can not slip through later in the process
or delay the process afetr IESG approves.
- I believe that the ID-Checklist also helped Henrik write the id-nits tool
will do a check for most of the checlist items that can (reasonably) be
checked by software
I remember that before we had the ID-Checklist, we often wasted a lot of
on this simple things (be it by taking a DISCUSS, by interacting with the
by adding RFC-Editor notes, By later checking if things were fixed, By later
discussing aith editors/authos why such little fixes were made etc etc ect).
So I believe it has served its purpose very well.
And I also believe that the intended purpose is still served very well with
current version, albeit that some clarifications an dupdates to ptrs and
citations/references are in order.
Pls do not consider this ID-Checklist as part of our BCP approved process
documents. That is not the intention of it and I think it would be bad to
try and make it part of our set of BCPs that describe our (IETF) process.
So I am not prepared yet to take on a massige reorg and as a result
probably a long discussion and wordtsmitting effort.
If Russ (or the IESG) tells me that they DO want a complete re-org I will
re-consider. But that was/is not the task I was asked to do (I believe).
I hope you understand
Editor of the ID_Checklist.
----- Original Message -----
From: "John C Klensin" <john-ietf(_at_)jck(_dot_)com>
To: <dcrocker(_at_)bbiw(_dot_)net>; "Bert Wijnen (IETF)"
Cc: "IETF Discussion" <ietf(_at_)ietf(_dot_)org>
Sent: Saturday, August 09, 2008 8:30 PM
Subject: Re: Call for review of proposed update to ID-Checklist
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,
--On Saturday, 09 August, 2008 09:20 -0700 Dave Crocker
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
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
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.
Ietf mailing list