Re: Call for review of proposed update to ID-Checklist

["Bert Wijnen \(IETF\)" <[e-mail]>]

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 
that
  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 
time
on this simple things (be it by taking a DISCUSS, by interacting with the 
authors,
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 
the
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

Bert
Editor of the ID_Checklist.

----- Original Message ----- 
From: "John C Klensin" <[e-mail]>
To: <[e-mail]>; "Bert Wijnen (IETF)" <[e-mail]>
Cc: "IETF Discussion" <[e-mail]>
Sent: Saturday, August 09, 2008 8:30 PM
Subject: Re: Call for review of proposed update to ID-Checklist


> 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
> <[e-mail]> 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 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf