[rfc-i] Fwd: I-D ACTION:draft-hoffman-rfc-author-guide-00.txt
rousskov at measurement-factory.com
Fri Sep 3 11:00:20 PDT 2004
On Fri, 3 Sep 2004, Paul Hoffman / VPNC wrote:
> At 11:08 AM -0600 9/3/04, Alex Rousskov wrote:
>> ... there is a significant difference between what draft authors
>> should produce and what RFC Editor will make out of their drafts.
> Yes, exactly.
>> For example, draft authors may produce a draft without ToC,
>> headers, footers, proper sentence spacing, etc. Then, if the draft
>> is published as an RFC, those things get added or changed by the
>> RFC Editor.
Thanks for clarifying my doubts! I believe the approach you are
documenting is fundamentally wrong in IETF context. IMHO, RFC Editor
SHOULD NOT accept drafts that require modifications. Nor should IESG
review such drafts, for that matter. It should be authors
responsibility to comply with all the rules, without spending precious
IETF resources. And RFC Editor and IESG should be prohibited from
wasting time on fixing drafts to comply with the rules.
I believe achieving that ideal would require a different approach to
documenting the rules, among other things.
> It has always been this way.
Agreed. And, IMO, it is causing an exponentially growing number of
>> You are happy with that because it lets authors use tools that are not
>> aware of RFC requirements (e.g., easily format the entire draft using an
>> ordinary plain text editor).
> My happiness is not relevant here. What I'm trying to do is to make clear
> what is needed, suggested, and optional for RFC authors.
Your (and other IETFers) happiness should be the key. If a process is
badly broken and does not make you happy, documenting and
re-documenting it is a waste of time at best and further cementing the
broken process at worst.
> My vision of "good practice", which I hope comes through in the
> draft, is that ID authors must do all that is required, and should
> do (or at least consider) all that is suggested.
IMO, if there is energy to re-document drafting requirements, we
should spend it to make sure that virtually no authors produce drafts
that require RFC Editor changes. Doing so requires different
documentation, new tools, and different RFC Editor/IESG policies, all
of which is something we (collectively) can produce, influence, and
Specifically, if RFC Editor wants to always enforce a rule, we must
document it and produce tools to check compliance. Drafts clearly
violating the rule should be automatically rejected without spending
any of the RFC Editor time (with a slow manual appeal mechanism, of
course). And vice versa, if RFC Editor does not want to always enforce
a rule, submitted drafts must not be changed to enforce that rule
More information about the rfc-interest