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

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

inline
----- Original Message ----- 
From: "Dave Crocker" <[e-mail]>
To: "Bert Wijnen (IETF)" <[e-mail]>
Cc: "Brian E Carpenter" <[e-mail]>; <[e-mail]>; 
<[e-mail]>
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 
> 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.
>
> 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.)
>

I can change the pointer to
    http://www.rfc-editor.org/policy.html#policy.authlist

if that helps.

Again, a lower case "should" is certainly not nromative in the sense you 
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.

>
>
>> 1.  Introduction
> ...
>> As a suggestion for productivity improvement, it is strongly RECOMMENDED 
>> to use XML2RFC
>
> The capitalization appears intended to offer essentially normative 
> guidance but,
> of course, that's probably not what is meant.
>

wow... some of you seem to jump to RED-Alert when you see a capitalized
term. It is there as strong advise. I personally have no problem changing
that to lower case. I am checking with IESG on that.

>
>
>> 2.2.  Required sections - all I-Ds
>>
>> The following are REQUIRED sections in all Internet-Drafts:
>
> What is the basis for asserting that this list is *required* (and, by the 
> way,
> is "required" meant as a normative term; the caps suggest yes)?  Again, 
> please note that I'm not claiming the list is wrong, but that its 
> provenance is absent. So your view that "Our processes are described in 
> formally approved BCP documents" might be at risk.
>
I can live with making it lowercase (I am checking with IESG).
The first MUST in point 1 in sect 2.2 is certainly based on a real thing.
But even if we make all the capitalized MUST/SHOULD/RECOMMENDED
lower case, even then the ID_Checklist is very usefull.

>
>
>> 3.  Content issues
> ...
>> B. no citations
>
> While I happen to think this is quite good advice, I have no idea a) where 
> it
> comes from, or b) whether it is guidance or requirement.
>

comes from RFC-Editor. See last para in
   http://www.rfc-editor.org/policy.html#policy.abstract
I can add the pointer if that helps.

> The one before it, "Should be meaningful to someone not versed in the
> technology" also lacks basis.  Further, as guidance, it's reasonable, but
> entirely lacking in substance to help an author know how to satisfy it.
>
>

It came from rfc2223bis or at least how I (and the IESG at the time of first
ID_Checklist revision) interpreted:

      The Abstract section should provide a concise and comprehensive
      overview of the purpose and contents of the entire document, to
      give a technically knowledgeable reader a general overview of the
      function of the document.  In addition to its function in the RFC
      itself, the Abstract section text will appear in publication
      announcements and in the online index of RFCs.

I think the intent is that the reader of an abstract of course should be
somewhat technically knowledgebale, but that he/she should not have
to be an expert in the technology described in the document. I.e.
the abstract is intended for technically knowledgeable people that
have not participated in the production of the RFC (or the
technology described in the RFC).
If you have better wording to suggest, pls do so.

>
> and also from that section:
>
>> 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 published, new claims may come in,
So the IPR Notice from RFC3979 makes it clear that there *may* (my emphasis)
be IPR claims, but that you must go to the IETF IPR disclosure web pages to
see which ones (if any) there are.

> And so on.
>

Pls point out all the issues/concerns you have (if you want a personal email
is fine). As you probably know, things that seem obvious for the editor of
a document may not be obvious to readers of the document.

Bert
> d/


_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf