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 19:25 +0200 Eliot Lear
<[e-mail]> wrote:

> Can we distill the high level point that needs addressing in
> this process?
> 
> Are the touch points and flow the responsibility of the RFC
> Editor to define, or should that be this group?

Eliot, 

I think "touch points and flow" is an oversimplification and
that this thread illustrates that.  Let me see if I can divide
things up without going on too long about it.

(1) This particular issue is out of scope because the problem is
probably exclusive to the IETF streams.  If other streams have
the same issues, we haven't heard about them, but, even if they
have, per-stream solutions are likely to be needed.   I don't
think there is any reason to make reconsideration of the stream
model part of this process.

(2) At the same time, the question of the responsibilities and
authority of the RFC Editor Function seems to me to be very much
on-topic.  Historically, the RFC Editor has always had the
authority to say "this is not publishable in its current form,
please fix it" (see Appendix A.2 of draft-flanagan-7322bis-05,
posted today).  In ancient times (i.e., during the
Postel-Reynolds period) drafts were periodically bounced because
they were not coherent enough to be editable with reasonable
resources.  Btw, in those times, drafts were also bounced
because the RFC Editor judged them to be technically incoherent.
And, sometimes the RFC Editor would apply a "fix" to a document
that had substantive technical input... and a few incidents of
that were what set us on the path to having an AUTH48 process.
However, in more recent times, when the RFC Editor has pushed
back (and I'm not aware of that occurring in many years, so what
I'm about to say is not a criticism of any present or recent
IESG), the responses from the IESG were rather hostile.. and
that is why we have an explicit provision that says the IESG can
tell the RSE/RPC to publish a document exactly as the IESG
prefers with the RFC Editor able to only add a note indicating
that occurred.

I think that immediately goes to two types of questions I think
are in scope and, indeed, critical for this group:

(a) Noting that the decision to edit (or not) a problematic
document will often have consequences on overall workflow, do we
want the decision as to whether to do so be made by the RPC in
conjunction with (or under the authority of) the RSE or under
the authority of the Executive Director (who may have no
publication or editing experience).  If general guidelines are
developed within the RFC Editor Function about the properties
that should cause a document to be pushed back, is that an RSE
function, an RPC one without the RSE, of an Executive Director
matter?

(b) Is the RSE ultimately independent or simply a contractor who
can be managed, and whose decisions can be second-guessed, by
the IESG, IAB, RSOC, or some other group, either directly or via
the Executive Director?

thanks,
   john