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

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

--On Wednesday, March 2, 2022 16:14 -0800 Christian Huitema
<[e-mail]> wrote:

> On 3/2/2022 12:31 PM, Brian E Carpenter wrote:
> 
>> Joel's concern is reasonable but I think the boundary between
>> policy and operations will always be hard to fix precisely.
>> 
>> That said, I slightly disagree with Lars. It's *exactly*
>> because the policy requirements might differ between streams
>> that the RSWG/RSAB structure is the right place to discuss
>> this. To be specific, the lack of public debate about
>> non-editorial changes at AUTH48 is of real concern in the
>> IETF standards process, but might be considered a non-issue
>> for the Independent Stream. And the desired settings might be
>> different for the other three streams (including the new
>> Editorial stream). That - public debate during AUTH48 - would
>> be a policy issue. The details of which mailing lists and/or
>> version management systems are used is operational. 
> 
> The request to make AUTH48  discussions public is rooted in
> the standard making requirements. RFCs coming out of the IETF
> streams are standard documents. The process must be fully
> transparent, if only to avoid appearances of last minute
> backroom dealing. The responsibility for ensuring the
> requiring transparency is squarely on the IESG and the IETF
> chair, not on the RSWG/RSAB or the RPC.

But (i) AUTH48 is used by all four existing streams, (ii) even
if the IETF stream, it is used for non-standards track documents
as well as standards track ones.  

It may be that neither of those makes a difference.   However,
in the IETF Stream (with, AFAICT, parallels in the others), the
AD with responsibility for the document has the responsibility
for saying "Hey, the questions that have been raised and/or the
changes that have been required, are large enough that there is
a possibility that the document does not represent IETF
consensus.  We need to pull it back and hand the new working
version back to the WG (for WG documents) and/or issue a new
Last Call (for everything).  I don't see making the discussions
more public actually helping with that except for after-the-fact
arguments about what went wrong (if something did).

I should also point out that sometime unfortunate changes have
been made to documents after Last Call but not in editing but in
decisions made or requested during IESG discussion and balloting.

I would have written your last sentence as saying that the
responsibility for ensuring that the document that gets through
AUTH48 and gets published is technically (and in any other
substantive way) the same as the one that went through IETF Last
Call is squarely on the IESG, particularly the responsible AD.
If one is concerned that is not adequate (last minute backroom
dealing or not, it seems to be that it would be far more
effective to require, as I suggested a while ago, that, after a
document clears AUTH48, that version be posted for final
community review as an I-D --with the potential to appeal or
otherwise force additional IESG or community review rather than
publishing a short time later-- rather by making (or expecting)
the community to wade through discussions of, e.g., punctuation
or capitalization in order to see if substantive errors or
deviations from community decisions were made.  

In the general case, I don't see a problem making the AUTH48
discussions public for those who might be fascinated by them or
have excess time on their hands.  But, if the problem you are
trying to solve is the suspicion of the content of standards
being distorted by nefarious actions, I don't think it is likely
to be efficient at catching those problems.

And I still believe that this discussion is not desirable for
this list at this point and should be handed off to the RPC.  If
this RSWG doesn't consider the decisions the RPC makes to be
appropriate, they should by all means take it up.

   best,
    john