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

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

 





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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

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