gmane.ietf.general

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

This suggests to allow more gTLDs for use as examples.
It seems to me that that would mean an update to RFC2606,
an I consider that out of scope for the ID-Checklist document.

So I will ignore all discussion on this for the current updates.
If an updated 2606 ever occurs, I will accept to update
ID-Checklist accordingly.

Bert
Editor of ID-Checklist

----- Original Message ----- 
From: "Bill McQuillan" <McQuilWP <at> pobox.com>
To: "IETF Discussion" <ietf <at> ietf.org>
Sent: Wednesday, July 09, 2008 6:37 PM
Subject: Re: Call for review of proposed update to ID-Checklist

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

On Wed, 2008-07-09, Spencer Dawkins wrote: 
> If an example describes a complex network topology, it could be 
> appropriate to use a variety of names, IP addresses or prefixes that are 
> easily disambiguated, so that the reader might follow the example more 
> easily. 

I wonder if it would make it easier to use "example" DNS names if, in 
addition to the verbose and clumsy: "*.example", IMHO, we reserved gTLDs 
like "*.foo", "*.bar", "*.bat", "*.baz", as well as the one used quite 
frequently on this list lately: "*.tld", for use as example DNS names.

(Continue reading)

headers

Dave Crocker | 9 Aug 18:20

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

Bert Wijnen (IETF) wrote:
> My approach is to clearly make those changes that are straight forward,
> simple end editorial.
> For other changes, I need to hear (I guess from Russ) that there
> is consensus to make such a change.

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?  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.

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.

That discussion is then more likely to produce the kind of input that will help 
Russ make those consensus assessments.

d/

(Continue reading)

headers

John C Klensin | 9 Aug 20:30

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
<dhc2 <at> dcrocker.net> 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

(Continue reading)

headers

Bert Wijnen (IETF | 9 Aug 20:52

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

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

(Continue reading)

headers

John C Klensin | 9 Aug 21:58

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

--On Saturday, 09 August, 2008 20:52 +0200 "Bert Wijnen
\\(IETF\\)" <bertietf <at> bwijnen.net> wrote:

> 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:

Bert,

We are in complete and utter agreement with each other about the
appropriate role of the ID_Checklist.  For better or worse, the
IESG apparently does not agree, as evidenced most recently in
their response to my appeal about turning a suggestion from the
original version of the Checklist into a firm rule without
having that explicitly confirmed by the community.

We also agree that revising the Checklist into a document that
is suitable for use as part of a package of firm rules is a
rather different job than updating it while being consistent
with its original purpose.

(Continue reading)

headers

Brian E Carpenter | 11 Aug 01:07

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

On 2008-08-10 07:58, John C Klensin wrote:
> 
> --On Saturday, 09 August, 2008 20:52 +0200 "Bert Wijnen
> \\(IETF\\)" <bertietf <at> bwijnen.net> wrote:
> 
>> 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:
> 
> Bert,
> 
> We are in complete and utter agreement with each other about the
> appropriate role of the ID_Checklist.  For better or worse, the
> IESG apparently does not agree, as evidenced most recently in
> their response to my appeal about turning a suggestion from the
> original version of the Checklist into a firm rule without
> having that explicitly confirmed by the community.
> 
> We also agree that revising the Checklist into a document that
> is suitable for use as part of a package of firm rules is a
> rather different job than updating it while being consistent

(Continue reading)

headers

John C Klensin | 11 Aug 01:52

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

--On Monday, August 11, 2008 11:07 AM +1200 Brian E Carpenter 
<brian.e.carpenter <at> gmail.com> wrote:

>> So I withdraw my suggestion and comments but strongly suggest
>> that you make sure that your intentions for the document and
>> those of the IESG are in synch before proceeding much further.
>
> I'd like to say that both as an author and as a reviewer, I
> have always found both the ID checklist and the IDnits checker
> to be of immense pragmatic value.

I agree.   I've just had a painful recent experience (not the 
first one) in which some overzealous person has assumed that 
some provision of one or the other is actually a firm rule and 
proceeded to try to enforce it in some draconian fashion.  I 
don't believe that is wise, appropriate, or healthy.   So I'm 
trying to be sure that the Checklist is clear about both its 
overall intent and the strength of any guidelines it presents in 
the hope of preventing that sort of behavior in the future.

> Obviously, if the checklist
> or the checker complains about something that isn't obviously
> a bug, the author, shepherd, AD or reviewer will have to enter
> "think" mode or even "negotiate" mode. I agree that it's a
> good idea to be clear about that.

Either "think" mode or "negotiate" mode would be a considerable 
improvement over what has appeared to be "this is a rule, it is 
immutable, change your document".

(Continue reading)

headers

Bert Wijnen (IETF | 11 Aug 10:24

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

I personally very much like this statement from Brian Carpenter:

> I'd like to say that both as an author and as a reviewer, I have
> always found both the ID checklist and the IDnits checker to be
> of immense pragmatic value. Obviously, if the checklist or the
> checker complains about something that isn't obviously a bug,
> the author, shepherd, AD or reviewer will have to enter "think"
> mode or even "negotiate" mode. I agree that it's a good idea
> to be clear about that.
> 
>    Brian
> 
>

I am checking with the IESG if they also agree with that

Bert
Editor for the ID_Checklist

headers

Frank Ellermann | 9 Aug 22:28

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

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.

(Continue reading)

headers

Dave Crocker | 10 Aug 17:38

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

Bert Wijnen (IETF) wrote:
> 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 
> are described in formally approved BCP documents.

Bert,

I am trying to distinguish between what the Checklist "is intended to be" from 
the competing views of what it actually is, as discussed in this thread 8-11 
July.  That thread made clear that a variety of serious and thoughtful people 
have very different views on the actuality.

This sort of debate is never resolved by abstract exchanges. It needs hard data.

I think your previous note correctly listed what the document was (and probably 
is) *intended* to be.  I think the thread made clear there is a strong case that 
the document has become more than that. I think it also made clear that the 
basis for its becoming more is fuzzy.

So my suggestion is not seeking to directly resolve the matter, but rather to 
provide a tool for discussion.  Simply put, it adds an audit trail to the 
document's content that should help folks by providing some relatively objective 
information that makes clear what is and is not based on rules defined elsewhere.

Hence, I am hoping that detailed attention to John's note following-up my own 
suggestion comes later, since I read it as possibly seeking to resolve things 
directly. More probably, he was merely trying to help make the case for why the 
document needs substantiation of its particulars.

(Continue reading)

headers

SM | 11 Aug 19:42

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

At 11:52 AM 8/9/2008, Bert Wijnen \(IETF\) wrote:
>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.

[snip]

>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.

The IESG pointed to the ID-Checklist in its response to an 
appeal.  If the intention is not to have the ID-Checklist as part of 
the approved process documents, it shouldn't be used as a formally 
approved document.

Regards,
-sm

headers

Bert Wijnen (IETF | 9 Aug 21:33

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

Ted, a glib response would be:

     We can ask the RC-Editor to fix everything that is broken

But do we (IETF/ISOC) really want to spend a lot of real money on
payed RFC-Editor to fix up things that authors/editors can easily do,
specifically with a ID-Checklist in hand that points out the many
simple "things-to-fix" that we often found in many submitted
I-Ds?

My take is that we should put that responsibility with the
authors/editors and the WG chairs. That is what the document
does, and that is also what a WG chair is asked to check
when they fill out the questionaire in RFC4848 in section
3.1, The shepherd (often WG chair) is asked to confirm that he did check
the document to meet the ID-Checklist (see question 1.g on page 6).

And that SAVES a lot of time on already overloaded ADs/IESG
and also SAVES real dollars in the RFC-Editor cycle.

Bert
Editor for ID_Checklist

----- Original Message ----- 
From: "Theodore Tso" <tytso <at> mit.edu>
To: "Pete Resnick" <presnick <at> qualcomm.com>
Cc: "IETF Chair" <chair <at> ietf.org>; <ietf <at> ietf.org>; <iesg <at> ietf.org>
Sent: Tuesday, July 08, 2008 11:35 PM
Subject: Re: Call for review of proposed update to ID-Checklist

(Continue reading)

headers

Paul Hoffman | 10 Aug 17:18

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

An additional check should be added to the list: all URLs that are 
meant to be able to be resolved must actually resolve at the time of 
submission.

For example, the first URL in the ID-Checklist document does not resolve...

--Paul Hoffman, Director
--VPN Consortium

headers

Julian Reschke | 10 Aug 18:03

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

Hi,

things I'd like to see done in IDs more consistently:

In an Editorial Note on the front page:

- state on which mailing list discussions should take place (include 
mailing list archive and subscription links)

- point to issues lists when available

References:

- check that if the document obsoletes or updates another document, that 
one appear in the references section, and make sure that the document 
actually says what's going on with respect to the other documents (such 
as "Normative Changes from RFC xxxx")

- use symbolic references

- when quoting RFCs, consider calling out a specific section in the 
referenced document (it's preferable that the author does it once, 
instead of the readers having to figure it out; also, it helps revising 
the document when the referenced document was revised)

Code:

- when using xml2rfc, add type parameters to artwork so that things like 
ABNF can be automatically extracted and checked

(Continue reading)

headers

John C Klensin | 11 Aug 01:32

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


--On Sunday, August 10, 2008 6:03 PM +0200 Julian Reschke 
<julian.reschke <at> gmx.de> wrote:

> Hi,
>
> things I'd like to see done in IDs more consistently:
>
> In an Editorial Note on the front page:
>
> - state on which mailing list discussions should take place
> (include mailing list archive and subscription links)
>
> - point to issues lists when available
>
>
> References:
>
> - check that if the document obsoletes or updates another
> document, that one appear in the references section, and make
> sure that the document actually says what's going on with
> respect to the other documents (such as "Normative Changes
> from RFC xxxx")

Of course, if one does this, the automated nits checker 
complains about a reference to an obsolete RFC 

> - use symbolic references

The RFC Editor is still flexible about this, IMO for good

(Continue reading)

headers

Julian Reschke | 11 Aug 07:46

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

John C Klensin wrote:
> ...
>> References:
>>
>> - check that if the document obsoletes or updates another
>> document, that one appear in the references section, and make
>> sure that the document actually says what's going on with
>> respect to the other documents (such as "Normative Changes
>> from RFC xxxx")
> 
> Of course, if one does this, the automated nits checker complains about 
> a reference to an obsolete RFC 
> ...

It's only a warning if it is an informative reference...

> ...
>> Code:
>>
>> - when using xml2rfc, add type parameters to artwork so that
>> things like ABNF can be automatically extracted and checked
> 
> FWIW, I continue to believe, based on experience with a few fairly large 
> and complex documents (most recently rfc2821bis) that the xml2rfc 
> approach of treating ABNF as a special type of artwork is seriously 
> broken for at least two reasons:

I do agree that the approach of "either it is prose or it is artwork" 
does not work well for things lik e BNF, example mssages and so on...

(Continue reading)

headers

Lars Eggert | 11 Aug 09:52

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

Hi,

On 2008-8-11, at 2:32, ext John C Klensin wrote:
> --On Sunday, August 10, 2008 6:03 PM +0200 Julian Reschke <julian.reschke <at> gmx.de 
> > wrote:
>> - check that if the document obsoletes or updates another
>> document, that one appear in the references section, and make
>> sure that the document actually says what's going on with
>> respect to the other documents (such as "Normative Changes
>> from RFC xxxx")
>
> Of course, if one does this, the automated nits checker complains  
> about a reference to an obsolete RFC 

you only get an (incorrect) warning if the referenced RFC has  
_already_ been obsoleted by another document. For the normal case -  
document B obsoleting document A - there is no warning when B  
references A, because A's status changes to "obsolete" only after B is  
IESG-approved.

And as Brian correctly points out, idnits warnings/errors are  
sometimes bogus, which is where "think mode" comes in.

Lars

headers

Bert Wijnen (IETF | 11 Aug 09:52

ID desires and TOOLS stuff [was: Re: Call for review of proposed update to ID-Checklist]

All, 

PLEASE change the subject line if you change the topic to be discussed.

I do NOT think that the below has anything to do with my editing (or the
Call for review) of the ID_Checklist. 

The below list seems like a new set of desires that some people have
w.r.t. Internet Drafts (and resulting RFCs). The listed items may all be 
things for authors/editors to consider. They may also be things that 
some TOOL could possibly detect and warn about. But they are not
(and in my view should not be) topics of the ID_Checklist.

So I am not considering the below (and follow up discussions) as
part of my current editing cycle of ID-Checklist.

Bert
Editor for ID_Checklist.

----- Original Message ----- 
From: "Julian Reschke" <julian.reschke <at> gmx.de>
To: <ietf <at> ietf.org>
Sent: Sunday, August 10, 2008 6:03 PM
Subject: Re: Call for review of proposed update to ID-Checklist

> Hi,
> 
> things I'd like to see done in IDs more consistently:
> 
> In an Editorial Note on the front page:

(Continue reading)

headers

Bert Wijnen (IETF | 9 Aug 21:41

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

As you all can see, the ID-Checklist in fact DOES refer to
the rfc2223bis at many places. It has now been updated (in my copy)
to point to the RFC-Editor-Style Manual. Specifically section 2
discusses this, and sect 2.1 starts out by stating:

   In principle, the RFC-Editor can take care of a few small formatting 
errors.
   And if there are only a few, then they will do so. However, if many 
errors
   exist, the document will be returned to the author(s)/editor(s)/WG for 
fixes.
   In any event, please realize that not following the formatting rules will 
most
   probably delay publication and does consume time that can be spend on
   other work.

It could be made clearer that the ID-Checklist is specifically intended for
final I-Ds that are submitted to an AD, i.e. a request for publication
to the AD/IESG.

The first Note in the Introduction section does say so.
But to be more clear, I have changed the fuirst sentence of sect 1.
from

    All Internet Drafts which are offered for publication as RFCs

into

    All Internet Drafts which are offered to an AD or the IESG with a 
request

(Continue reading)

headers

Dave Crocker | 10 Aug 18:14

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

Bert,

Bert Wijnen (IETF) wrote:
> As you all can see, the ID-Checklist in fact DOES refer to the rfc2223bis at
>  many places.

Yes, but...

1. draft-rfc-editor-rfc2223bis is expired.

2. While the citations that are included mostly do include the specific section
to look in, some do not.  (See the first example, below.) Hence, some of the
citations are too broad.

3. Much of the document's direction is offered without citation.

 From the July 4 <http://www.ietf.org/ID-Checklist.html>...

> 2.2.  Required sections - all I-Ds
...
> List of authors/editors
> 
> There should not be more than 5 authors/editors (see 
> http://www.rfc-editor.org/policy.html)

The Policy document is about 10 pages long.  I thought the specific information
would be in "Authors vs. Contributors" but it wasn't.   One has to search awhile
to find Item #1 under an interestingly named section "Author Overload", to find
the basis for the "should" in the checklist.

(Continue reading)

headers

John C Klensin | 10 Aug 23:32

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

--On Sunday, August 10, 2008 9:14 AM -0700 Dave Crocker 
<dhc2 <at> dcrocker.net> wrote:

>...
>> 2.2.  Required sections - all I-Ds
> ...
>> List of authors/editors
>>
>> There should not be more than 5 authors/editors (see
>> http://www.rfc-editor.org/policy.html)
>...

> And note that the normative "should" language in the
> Checklist, here, might be
> considered stronger than what is actually said in the RFC
> Editor's policy
> document.  (One can debate this, but then, that debate is
> exactly what we ought
> to have, based on hard data like this. My own opinion is that
> the "should" is
> appropriate here, in terms of actual practice, and it's long
> been what I advise folk writing drafts.)

And this is precisely one of the examples to which I was 
referring, because, in exceptional circumstances, the RFC Editor 
has been willing to negotiate that limit.  However, if my memory 
is correct, the "nits" checker, which draws its authority from 
the Checklist, gets sufficiently annoyed about more than five 
authors to prevent posting of I-Ds.

(Continue reading)

headers

Henrik Levkowetz | 11 Aug 00:54

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

Hi John,

On 2008-08-10 23:32 John C Klensin said the following:
> 
> --On Sunday, August 10, 2008 9:14 AM -0700 Dave Crocker 
...
>> And note that the normative "should" language in the
>> Checklist, here, might be
>> considered stronger than what is actually said in the RFC
>> Editor's policy
>> document.  (One can debate this, but then, that debate is
>> exactly what we ought
>> to have, based on hard data like this. My own opinion is that
>> the "should" is
>> appropriate here, in terms of actual practice, and it's long
>> been what I advise folk writing drafts.)
> 
> And this is precisely one of the examples to which I was 
> referring, because, in exceptional circumstances, the RFC Editor 
> has been willing to negotiate that limit.  However, if my memory 
> is correct, the "nits" checker, which draws its authority from 
> the Checklist, gets sufficiently annoyed about more than five 
> authors to prevent posting of I-Ds.

Umm???

If you're referring to idnits, it does no test the number of authors
in any way or form.  I haven't checked whether the current, soon-to
be replaced submission tool tries to check this, but idnits does
most emphatically not.

(Continue reading)

headers

John C Klensin | 11 Aug 01:46

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


--On Monday, August 11, 2008 12:54 AM +0200 Henrik Levkowetz 
<henrik <at> levkowetz.com> wrote:

>> And this is precisely one of the examples to which I was
>> referring, because, in exceptional circumstances, the RFC
>> Editor  has been willing to negotiate that limit.  However,
>> if my memory  is correct, the "nits" checker, which draws its
>> authority from  the Checklist, gets sufficiently annoyed
>> about more than five  authors to prevent posting of I-Ds.
>
> Umm???
>
> If you're referring to idnits, it does no test the number of
> authors
> in any way or form.  I haven't checked whether the current,
> soon-to
> be replaced submission tool tries to check this, but idnits
> does most emphatically not.

I apologize to idnits.   I have seen documents rejected by some 
process because they had more than five authors, but I don't 
remember whether it was the submission tool or someone 
overzealous at the (present or past) Secretariat.

    john

headers

Henrik Levkowetz | 11 Aug 10:21

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

Hi John,

On 2008-08-11 01:46 John C Klensin said the following:
> 
> --On Monday, August 11, 2008 12:54 AM +0200 Henrik Levkowetz 
> <henrik <at> levkowetz.com> wrote:
...
>> If you're referring to idnits, it does no test the number of
>> authors
>> in any way or form.  I haven't checked whether the current,
>> soon-to
>> be replaced submission tool tries to check this, but idnits
>> does most emphatically not.
> 
> I apologize to idnits.   I have seen documents rejected by some 
> process because they had more than five authors, but I don't 
> remember whether it was the submission tool or someone 
> overzealous at the (present or past) Secretariat.

Ok.  Which leaves establishing the desired behaviour of the draft
submission mechanisms.  

My personal viewpoint is that it would be inappropriate to strictly
enforce a limit of 5 authors.  The use of 'should' in section 2.2,
item 2 of the current document ('There should not be more than 5
authors/editors') seems appropriate given the current RFC Editor
policy, and tools-wise this would then be implemented as a note or
warning at the most, but should never cause a refusal to accept a draft
submission.

(Continue reading)

headers

Julian Reschke | 11 Aug 10:28

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

Henrik Levkowetz wrote:
> ...
> Ok.  Which leaves establishing the desired behaviour of the draft
> submission mechanisms. 
> My personal viewpoint is that it would be inappropriate to strictly
> enforce a limit of 5 authors.  The use of 'should' in section 2.2,
> item 2 of the current document ('There should not be more than 5
> authors/editors') seems appropriate given the current RFC Editor
> policy, and tools-wise this would then be implemented as a note or
> warning at the most, but should never cause a refusal to accept a draft
> submission.
> ...

+1

BR, Julian

headers

Dave Crocker | 11 Aug 16:35

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

Henrik Levkowetz wrote:
  > My personal viewpoint is that it would be inappropriate to strictly
> enforce a limit of 5 authors.  The use of 'should' in section 2.2,
> item 2 of the current document ('There should not be more than 5
> authors/editors') seems appropriate given the current RFC Editor
> policy, and tools-wise this would then be implemented as a note or
> warning at the most, but should never cause a refusal to accept a draft
> submission.

1. "enforce a limit"  moves a should to a must.

2. The RFC Editor's policy document does not use language that is as strong as a 
should.

Hence, the ID Checklist is making a normative statement stronger than the RFC 
Editor and the proposal for the checker to 'enforce' is even stronger than that.

By contrast, last sentence suggesting simply printing a notice that there are 
more authors than preferred captures the RFC Editor policy's statement.

d/
--

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

headers

Henrik Levkowetz | 11 Aug 18:54

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

Hi Dave,

On 2008-08-11 16:35 Dave Crocker said the following:
> 
> Henrik Levkowetz wrote:
>   > My personal viewpoint is that it would be inappropriate to strictly
>> enforce a limit of 5 authors.  The use of 'should' in section 2.2,
>> item 2 of the current document ('There should not be more than 5
>> authors/editors') seems appropriate given the current RFC Editor
>> policy, and tools-wise this would then be implemented as a note or
>> warning at the most, but should never cause a refusal to accept a draft
>> submission.
> 
> 
> 1. "enforce a limit"  moves a should to a must.

Yes, but nobody is arguing that this should be done...

> 2. The RFC Editor's policy document does not use language that is as strong as a 
> should.
> 
> Hence, the ID Checklist is making a normative statement stronger than the RFC 
> Editor and the proposal for the checker to 'enforce' is even stronger than that.

Repeating myself in a new context:  Umm??

I didn't propose that the checker enforce such a limit, and I'm not aware of
anyone else proposing it, thus I don't understand why you seem to argue against
a proposal nobody seems to have made.  Have I misunderstood what you seem to
be saying immediately above, or have you misunderstood my position?

(Continue reading)

headers

Bert Wijnen (IETF | 11 Aug 10:51

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

inline
----- Original Message ----- 
From: "Dave Crocker" <dhc2 <at> dcrocker.net>
To: "Bert Wijnen (IETF)" <bertietf <at> bwijnen.net>
Cc: "Brian E Carpenter" <brian.e.carpenter <at> gmail.com>; <ietf <at> ietf.org>; 
<iesg <at> ietf.org>
Sent: Sunday, August 10, 2008 6:14 PM
Subject: Re: Call for review of proposed update to ID-Checklist

> Bert,
>
>
> Bert Wijnen (IETF) wrote:
>> As you all can see, the ID-Checklist in fact DOES refer to the rfc2223bis 
>> at
>>  many places.
>
> Yes, but...
>
> 1. draft-rfc-editor-rfc2223bis is expired.
>

I know. and the RFC-Editor has givem me a pointer to
    http://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt
which replaces rfc2223bis and this will be in the next revision (1.9)
as I had already stated in an earlier posting.

> 2. While the citations that are included mostly do include the specific 
> section
> to look in, some do not.  (See the first example, below.) Hence, some of

(Continue reading)

headers

Dave Crocker | 11 Aug 18:01

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

Bert Wijnen (IETF) wrote:
> I can change the pointer to 
> http://www.rfc-editor.org/policy.html#policy.authlist
> 
> if that helps.

It gets the reader to the right sections, so yes, it helps quite a bit.

> Again, a lower case "should" is certainly not nromative in the sense you

This semantic distinction between upper and lower case that folks keep making is
not supported by RFC 2119.  The RFC's "these words are often capitalized" does 
not mean "these words must always be capitalized in order to mean that they are 
normative."

Case distinction for semantics also goes against normal rules for English.

> seem to interpret it. Let me also say that this point became part of the 
> ID_Checklist after the RFC-Editor was exposed to I-Ds that had 15 or so
> people on the front page and then when the AUTH48 phase was entered it was
> enourmously time-comsuming and nearly impossible to reach (and get a
> response) from all the umpteen people on the front-page.

And yet the RFC Editor has not yet stated that this is a hard limit, nor has the
IETF consensus process imposed it.  So it makes no sense to have the Checklist 
mechanism enforce such a limit.

What we also have here is the usual debate problem with citing an extreme 
outlier (15 authors) as demonstrating a pervasive problem, while ignoring

(Continue reading)

headers

Bert Wijnen (IETF | 11 Aug 22:00

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

W.r.t.

----- Original Message ----- 
From: "Dave Crocker" <dhc2 <at> dcrocker.net>
To: "Bert Wijnen (IETF)" <bertietf <at> bwijnen.net>
Cc: <ietf <at> ietf.org>; <iesg <at> ietf.org>
Sent: Monday, August 11, 2008 6:01 PM
Subject: Re: Call for review of proposed update to ID-Checklist

... snip a lot ..

>>>> Specific IPR (e.g., patent claims & terms) must not be in an RFC
>>>
>>> The "must" is interesting.  What BCP documents this (entirely 
>>> reasonable,
>>> IMO) requirement?
>>>
>>
>> Does not point 4 4.  Specific IPR (e.g., patent claims & terms) must not 
>> be
>> in an RFC (or Internet-Draft). Any claims must go to the IETF IPR web 
>> page
>> and notice that there is some IPR claim. The mandatory IPR Notice from
>> [RFC3979] (Bradner, S., "Intellectual Property Rights in IETF 
>> Technology,"
>> March 2005.) section 5 points readers to the IETF IPR web page. clealry 
>> point
>> you to the basis (RFC3979) ??? The point was/is that some people put one
>> specific IPR claim in the RFC. And such is useless, after the RFC is
>

(Continue reading)

headers

Dave Crocker | 13 Aug 19:54

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

Bert Wijnen (IETF) wrote:
> ----- Original Message ----- From: "Dave Crocker" <dhc2 <at> dcrocker.net>
>> RFC 3979 says what is to be in an RFC, not what isn't. The Checklist says 
>> what isn't.
> 
> The proble we saw in the IESG (when we started ID_Checklist) was that we saw 
> A LOT OF I-Ds that requested publication and that DID HAVE SPECIFIC IPR 
> claims. So we wanted to make it clear to people that such is NOT TO BE DONE.
> 
> Just saying that RFC3979 text was to be used seemed not to get through!

Bert,

One of the likely reasons it didn't get through is that the IESG was inventing a
new rule.  A good rule, in my opinion, but a new one, since I think that
redundancy of specifications invites disparity.

To say that something must be in one place is very different from saying that it
may not (also) be in another.

So the IESG a) invented a more strict, formal rule than had existed before, and
b) only documented it in the Checklist.

Consider both of these points, please, in terms of your earlier claim:

> Bert Wijnen (IETF) wrote:
>> 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 are 
>> described in formally approved BCP documents.

(Continue reading)

headers

Dave Crocker | 13 Aug 19:55

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

Bert Wijnen (IETF) wrote:
> ----- Original Message ----- From: "Dave Crocker" <dhc2 <at> dcrocker.net>
>> RFC 3979 says what is to be in an RFC, not what isn't. The Checklist says 
>> what isn't.
> 
> The proble we saw in the IESG (when we started ID_Checklist) was that we saw 
> A LOT OF I-Ds that requested publication and that DID HAVE SPECIFIC IPR 
> claims. So we wanted to make it clear to people that such is NOT TO BE DONE.
> 
> Just saying that RFC3979 text was to be used seemed not to get through!

Bert,

One of the likely reasons it didn't get through is that the IESG was inventing a
new rule.  A good rule, in my opinion, but a new one, since I think that
redundancy of specifications invites disparity.

To say that something must be in one place is very different from saying that it
may not (also) be in another.

So the IESG a) invented a more strict, formal rule than had existed before, and
b) only documented it in the Checklist.

Consider both of these points, please, in terms of your earlier claim:

> Bert Wijnen (IETF) wrote:
>> 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 are 
>> described in formally approved BCP documents.

(Continue reading)

headers

Spencer Dawkins | 13 Aug 20:13

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

Hi, Dave,

> While it is vastly more convenient, for the IESG, to have it take 
> initiative and
> decide on its own to make a more strict rule and issue it in a document 
> that
> does not go through public vetting, it isn't the way things are supposed 
> to be
> done in the IETF.

Just to ring one of the changes here...

I'm actually OK with the process that Dave is not OK with, because I'm 
assuming that "public vetting" can also be retroactive - as long as the IESG 
announces rules publicly, I trust the community to point out problematic 
rules with great enthusiasm, and trust that the IESG will not go into 
"because we said so" mode when someone does point out that a new rule is 
problematic.

If my trust is misplaced, we have bigger problems than process changes, I 
think.

> If the IESG is now responsible for inventing IETF policy, that ought to be
> acknowledged and documented explicitly.

One of the many contortions we went through on process change was trying to 
distinguish between policy and procedure. Our "current"(?) process BCPs 
don't make this distinction well.

I'm totally good with the IESG inventing IETF *procedures*, and that's what

(Continue reading)

headers

Robert Elz | 14 Aug 07:45

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

    Date:        Wed, 13 Aug 2008 13:13:46 -0500
    From:        "Spencer Dawkins" <spencer <at> wonderhamster.org>
    Message-ID:  <0ed001c8fd70$55714430$ad600240 <at> china.huawei.com>

  | I'm actually OK with the process that Dave is not OK with, because I'm 
  | assuming that "public vetting" can also be retroactive - as long as the
  | IESG announces rules publicly,

I'm not.

The big difference is what consensus is needed to achieve what.

In the cases of even mildly controversial changes, and isn't
everything, the question is whether it requires (rough) consensus
to make the change, or requires (rough) consensus to overturn the
change.

Personally, I believe we need to achieve some form of agreement
before any changes, and not fall into the trap of: "it's done,
and some (enough) people believe it is OK, so there's no consensus
to not do it."

For what it's worth, on the issue that has been under discussion,
I see no harm at all in having documents list IPR claims they're
aware of, so long as they don't pretend to claim that those are
the only possible IPR claims.   For example, in the early 90's,
it would have been entirely reasonable for a doc proposing use of
RSA public key technology to note the patent status, in the doc.

Requiring that such information be only on the web page is just

(Continue reading)

headers

Frank Ellermann | 11 Aug 22:24

Mixed case (was: Call for review of proposed update to ID-Checklist)

Dave Crocker wrote:

> This semantic distinction between upper and lower case that
> folks keep making is not supported by RFC 2119.

As far as I'm concerned it is perfectly supported by RFC 2119:

The capitalized forms of the keywords have the defined meaning.
Other forms can have a different meaning.  And where they have
the same meaning they should be capitalized to avoid confusion.

RFC 2119 itself uses lower case "may", "must", "must not", and
"should" in several places where the precise meaning of the
capitalized words, i.e. the keywords, would not match. 

It is of course allowed to avoid mixed uses, but not required.

> Case distinction for semantics also goes against normal rules
> for English.

THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS 
SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY
THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.

 Frank

(Continue reading)

headers

Russ Housley | 12 Aug 16:28

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

I am working on a solution for this with the Secretariat.  It is one 
aspect of the web site redesign project.  I do not think that an 
Internet-Draft is needed.

Russ

At 11:40 AM 8/9/2008, Bert Wijnen \(IETF\) wrote:
>>(1) Archive older versions in a plain text format as for    I-Ds 
>>(for use with various IETF tools working on I-Ds)
>
>I can generate I-Ds if that helps. I can even submit those.
>Russ, do you want me to do that?

headers

Frank Ellermann | 13 Aug 02:25

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

Russ Housley wrote:

> I do not think that an Internet-Draft is needed.

The source is already a variant of xml2rfc input, from
there it's easy to arrive at plain text output for the
ordinary diff tools.  

Adding version numbers for archiving working with the
diff tool could be as simple as "use name-NN.txt for
version NN".

 Frank

> 
> Russ
> 
> At 11:40 AM 8/9/2008, Bert Wijnen \(IETF\) wrote:
> >>(1) Archive older versions in a plain text format as for    I-Ds 
> >>(for use with various IETF tools working on I-Ds)
> >
> >I can generate I-Ds if that helps. I can even submit those.
> >Russ, do you want me to do that?