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
reasonable exceptions (6 authors) that can and do occur.
We really need to get out of the habit of attempting to stop (or impose) change
by citing only one side of the issue -- and and extreme version of that side.
There are problems with change and with no change. The choice between them
should consider the *balance* of cost and benefit of the change and the cost and
benefit of no change.
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.
Bert, now I am completely confused. Above you stated "lower case 'should' is
certainly not normative" and yet here you take exception to the interpretation
of a capitalized term as implying that it is normative.
It is there as strong advise. I personally have no problem changing that to
lower case. I am checking with IESG on that.
How is the reader to know what is required and what is merely "advise"? We are
in the specification business. Where is the distinction specified?
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.
I don't recall anyone suggesting that the checklist or the checker weren't
useful. I thought that the discussion was how to make the *more* useful.
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.
Yup. Tnx.
The one before it, "Should be meaningful to someone not versed in the
technology" also lacks basis.
It came from rfc2223bis or at least how I (and the IESG at the time of first
ID_Checklist revision) interpreted:
The important point is that by having a citation, then we get to compare the
authoritative statement with the synthesis that made it into the checklist.
For the moment, it is really secondary as to whether that synthesis retained or
lost the useful information.
(FWIW, in terms of offering anything useful for the user of the Checklist, I
think it lost it. Note the massive difference in detailed guidance, such as for
2.1 Formatting, versus this entirely generic "Should be meaningful to someone
not versed in the technology." While "not versed in the technology" is a
somewhat useful tidbit, the Checklist text provides none of the affirmative,
semantic content guidance in the RFC Editor document.)
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
Bert, once again, I'm not suggesting the guidance is "wrong", but that it is
without substantiation. It asserts a *requirement* that it seems to have invented.
RFC 3979 says what is to be in an RFC, not what isn't. The Checklist says what
isn't.
And so on.
Pls point out all the issues/concerns you have (if you want a personal email
I did that: Each and every assertion that says or implies anything more than
"it can be helpful to do this" needs to provide a narrow citation for its basis.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf