inline
----- Original Message -----
From: "Dave Crocker" <dhc2@xxxxxxxxxxxx>
To: "Bert Wijnen (IETF)" <bertietf@xxxxxxxxxxx>
Cc: "Brian E Carpenter" <brian.e.carpenter@xxxxxxxxx>; <ietf@xxxxxxxx>;
<iesg@xxxxxxxx>
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf