[rfc-i] Fwd: I-D ACTION:draft-hoffman-rfc-author-guide-00.txt

[Alex Rousskov]

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.
>
> Correct.

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 
problems.

>> 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 
demand.

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 
selectively.

Alex.