Re: [Rfced-future] AUTH48 and editing before approval (was: Re: Welcome to the RFC Editor Future Development Program)

[John C Klensin <[e-mail]>]

--On Thursday, April 2, 2020 20:11 -0400 Russ Housley
<[e-mail]> wrote:

> John:
> 
> Just responding to the second point:
> 
>> Second, my concern (and, if I understood Christian's note, at
>> least part of his) is that we have too many documents that get
>> to the end of community review during Last Call and then
>> change enough via IESG action or RPC efforts to be only barely
>> recognizable as the same document.  The changes may be
>> substantive ones that the IESG considers minor or the writing
>> styles or skills in writing technical English of some authors
>> may have required major rewrites of paragraphs or sections by
>> the RPC.  I've rarely seen either cause harm, but the fact
>> remains that the community is signing off on one document and
>> then a different document is being published.  At least in
>> principle, that is a risk and maybe se should be thinking
>> about it and whether adjustments are in order (with the
>> understanding that reordering the editing and approval
>> processes is not the only option).
> 
> In the IETF, WG chairs, review teams, and ADs all have a role
> in turning back documents that are so poorly written that they
> need more that just copy editing.  I know that I have tried to
> do this in my working groups.  It is hard to tell someone that
> their document needs mush more work to be ready to progress,
> but that is the right place to apply the judgement.

Yes.  And that also means being much more careful about saying
"the RFC Editor will sort that out" -- something we heard
Heather comment on or complain about several times.  There are
many things about which that is appropriate and most of them
really are copy editing (capitalization, commas, grammar,...),
but many things that may not be.

> The RFC Editor ought to be able to tell the approving stream
> that the document is not ready for copy editing as well.  I
> understand that the RFC Production Center is very reluctant to
> do that.

Yes.  In part I assume because they have been treated badly when
they have tried to do that in the past (I knew several
instances, long ago, in which that did occur and assume that is
part of what made them reluctant).

I think this is something else we should come back to after we
have a new RSE in place and perhaps when we are far enough into
the xml2rfc v3 transition to have a clearer picture of levels of
effort but I wonder if things could be improved by asking the
RPC to make a very quick, triage-level, pass through a document
at about the time the IESG starts a Last Call.  The intention
would not be to start editing but rather to be able to give the
IESG quick advice -- advice for which the RPC would not be taken
to task if they got wrong -- about how much work and of what
sorts the document would need if it was approved in that form.
I could see the IESG, assisted by that sort of report,
tentatively approving a document after Last Call but returning
it to a WG for sorting out the explanation of technical
editorial details to the point that the intent of the
specification would be clear to all readers.  That wouldn't
eliminate the need for the RPC to do a copy editing job (and a
lightweight technical editing one), but it might well eliminate
many or most of the "did you really intend this to mean X or Y"
discussions at AUTH48 with all of the risks such questions imply.

best,
   john