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

[Dave Crocker <[e-mail]>]

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 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf