Re: [Rfced-future] [rfc-i] RSWG & AUTH48 (was Re: [admin-discuss] Public archival of AUTH48 communications)

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

--On Friday, March 4, 2022 12:02 -0800 Christian Huitema
<[e-mail]> wrote:

> On 3/4/2022 10:46 AM, John C Klensin wrote:
> 
>>> This is not a concern for the IESG. We have seen no evidence
>>> that the AUTH48 step is somehow systemically broken. (It does
>>> often take longer than 48 hours - but that has been the case
>>> for decades.)
>> I did not say "systematically broken" or anything like it.
>> Over the years, I've seen several cases in which questions
>> about clarity or ambiguity have come up during AUTH48 where
>> the possible solutions could have substantive technical
>> implications.  The decisions that have been made at that stage
>> have almost always been made based on beliefs about what the
>> WG intended or what the WG would say if asked.  AFAICT, those
>> decisions have almost always been made correctly made -- I
>> don't believe that I have ever (at least in the last couple of
>> decades) heard of participants in a WG complaining that a
>> document, as published, was not what they intended. However, I
>> still think it is reasonable to be anxious about that way of
>> making such decisions (although, frankly, not very anxious).
> 
> The process would be most transparent if the published version
> was exactly the version approved by the IESG. Or "almost
> exactly", if the changes were entirely predictable, such as
> removing text marked as "please remove before publication".
> But in my mind, rewriting paragraphs does not belong there.

Christian,

I don't think that is realistic, at least without either
sacrificing other values, moving to an "edit before Last Call"
model, or forcing WGs and the IESG into editorial roles.  Taking
those in order...

We've seen many document go into and through Last Call and
signed off by the IESG that were written by people whose skills
in writing clear technical English were less than superior.  To
be clear, while that group includes many people whose first
language was different, even very different, from English, it
also has included, e.g., documents written in the US by people
who have had all of their education in the US and who have still
not come out with clear technical writing as their strongest
skills.  While WGs often manage to sort out the worst problems,
our general practice has been that, if the meaning and intent of
the document are clear, to leave things to the RFC Editor to fix.

"Edit before Last Call" has been discussed many times, including
briefly on this list.  I can see many advantages for it, but the
clear consensus of the community has been that the costs --in
both time and financial resources-- are just too high.

So, let's assume that a document gets through Last Call and into
IESG review.  It is mostly comprehensible if one tries
reasonably hard and most readers would interpret the technical
provisions in the same way.  What should the IESG do?  Are we
willing to settle for "mostly comprehensible" and "most readers"
or do we continue to aspire to a higher standard?   Does the
IESG start editing?  Do they bounce the document back to the WG
and say "regardless of the LC comments, this isn't good enough,
please figure out a way to improve the quality of the writing
even if it means firing and replacing the editor"?   Something
else?

As I am sure the RPC and many members of the community would
agree, sometimes the right solution to a badly constructed
sentence is to rewrite it and a few surrounding ones, often even
a paragraph or more, rather than trying to make it a tiny bit
less bad by changing a word or two.  I think it would be really
unfortunate to restrict that type of change, especially when the
matter involved really is purely editorial.

Otherwise, much as many of us aspire to have documents in good
enough shape that the RPC doesn't have to do much work, I think
a "publish what the IESG delivers" policies would cause great
harm even though it would be more transparent.

    john