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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf