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

IETF Chair wrote:
>>From the discussion just prior to the recent appeal by John Klensin, it
> was clear that the guidance regarding example domain names in IETF
> documents provided in the ID-Checklist needed to be updated.  This point
> was emphasized further during the discussion of the Klensin appeal. 
> Proposed text is now available.  Many thanks to Bert Wijnen for continuing
> to edit the document.

1. Document scope and force

    This isn't a 'nits' or 'checklist' document.  It is a formal specification 
of requirements for RFC format and style, per "All Internet Drafts which are 
offered for publication as RFCs must conform to the following requirements or 
they will be returned to the author(s)/editor(s) for revision."

    That's fine, but that reality should be cast clearly, directly and from the 
start, including the Abstract.

    It also suggests that the document needs to receive a full IETF consensus 
approval.

    Small point of confusion: I thought the RFC document series was managed with 
some independence of the IETF.  As such, I'm not clear how the IETF (nevermind 
the IESG) can set the rules for RFC format and style.

    Please note that this is not meant to challenge the benefit of having clear 
and precise formal statement of RFC format and style.  It's just that it would 
be helpful to be clear about who is in charge, what the scope is, and whether 
the formal rules for decision-making are being followed.

2. Normative language

    The document uses normative language, some is in upper case and some is not. 
The document needs a careful pass for its use of normative language, to make it 
consistent and unambiguous.  An interesting current example is 3.1.A: "most 
abbreviations must be expanded on first use."  Semantically, I believe this 
means "abbreviations SHOULD be expanded on first use."  Simpler, clearer...

3.  Confusion of goals

    The document includes advice that might be quite a good idea, but it has 
nothing to do with RFC format or 'style' in the sense that a nits program can 
check.  For example "Avoid IPv4 specificity." sounds reasonable but is a 
massively generic suggestion.  Does it really belong in something supposedly 
getting at formatting issues?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf