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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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



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.



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.



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.

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.



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?




And so on.

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]