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

From: Lars Eggert <[email-masked]>
Date: Wed, 2 Mar 2022 16:41:46 +0100

Hi,

(changing the subject and adjusting the CC a bit.)

On 2022-2-26, at 18:50, John C Klensin <[email-masked]> wrote:
> Or maybe we postpone spending energy on new lists and tooling --
> both of which tend to create inertia for keeping "experiments"
> -- until the RSAB/RSWG are in place and, since AUTH48 is really
> part of the RFC Production process, allow them to define and
> oversee the experiment along with the IESG.

I thought about this a bit, and it's not immediately obvious to me that procedures for AUTH48 handling are under the purview of the RSWG. I could see an argument being made that they are under the purview of the individual streams. There are already minor differences between the streams, for example, the IRSG is in the loop for AUTH48 exchanges or the IRTF stream, but the IESG is not for the IETF stream.

It's true that so far, all streams have used - more or less, see above - the same process for handling AUTH48 processing. If that is intended to be one of the invariants of the RFC series, I agree that any changes would be under the purview of the RSWG, and any changes would then also apply to all streams.

But I could also see a future where one stream would want to revise how AUTH48 should be handled for their documents. If this is something we would like to allow - and personally (with no hats) I think that could be attractive - then I don't see how this could be under the purview of the RSWG, given that they are setting policies for the series (but not the individual streams).

Thanks,
Lars

---

From: Eliot Lear <[email-masked]>
Date: Wed, 2 Mar 2022 17:09:32 +0100

Hi Lars,

> But I could also see a future where one stream would want to revise how AUTH48 should be handled for their documents. If this is something we would like to allow - and personally (with no hats) I t…

I think the first question you have to ask is whether you have the 
appropriate decision points and processes defined with the RPC.  If you 
do, then this is not a matter for the RPC, since you are not asking for 
them to change anything.  At the point that you are asking them to 
change their processes, that is where the RSWG should come in, barring 
minor stuff.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Mar 2022 14:22:27 -0500

Lars Eggert <[email-masked]> wrote:
    > I thought about this a bit, and it's not immediately obvious to me that
    > procedures for AUTH48 handling are under the purview of the RSWG.

I don't mind if AUTH48 options are under the purview of the RSWG.
That might require that we ask the RSWG to amend itself, and I'm okay with that.

    > could see an argument being made that they are under the purview of the
    > individual streams. There are already minor differences between the
    > streams, for example, the IRSG is in the loop for AUTH48 exchanges or
    > the IRTF stream, but the IESG is not for the IETF stream.

It seems that there are a few boolean options that different streams might
want to turn on off, and at the least, we should say what they are.
In the end, it might be that things are the way they are because the
different stream managers were ignorant of the options.

    > It's true that so far, all streams have used - more or less, see above
    > - the same process for handling AUTH48 processing. If that is intended
    > to be one of the invariants of the RFC series, I agree that any changes
    > would be under the purview of the RSWG, and any changes would then also
    > apply to all streams.

I would prefer that AUTH48 process didn't varry much, or at all.

    > But I could also see a future where one stream would want to revise how
    > AUTH48 should be handled for their documents. If this is something we
    > would like to allow - and personally (with no hats) I think that could
    > be attractive - then I don't see how this could be under the purview of
    > the RSWG, given that they are setting policies for the series (but not
    > the individual streams).

I guess the only reason I think that we should allow variances is so that
smaller groups can try something new, innovate, and then report their
results.   It otherwise seems like change for change's sake to me.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 2 Mar 2022 20:29:12 +0100

On 2. Mar 2022, at 17:09, Eliot Lear <[email-masked]> wrote:
> barring minor stuff

This boundary seems to be infinitely low.

Grüße, Carsten

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 2 Mar 2022 14:33:17 -0500

I have rather the opposite concern about this conversation.  We seem to 
be moving in a direction where the RSWG is responsible for managing all 
aspects of the RPC operation.  Tactical as well as strategic.  That does 
not match what I thought we agreed.

Yours,
Joel

On 3/2/2022 2:22 PM, Michael Richardson wrote:
> _______________________________________________
> rfc-interest mailing list
> [email-masked]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Mar 2022 09:31:15 +1300

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.

    Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Mar 2022 23:23:08 +0000

Hiya,

On 02/03/2022 15:41, Lars Eggert wrote:
> I thought about this a bit, and it's not immediately obvious to me
> that procedures for AUTH48 handling are under the purview of the
> RSWG.
I think the procedures for auth48 should be driven by the
RPC, as IIUC has been the case. If there's need for some
policy change related to that then I'd say yes the RSWG is
the right body for that. But I'd hope that nit-picking
RPC procedures would be avoided by the RSWG (likely a job
for the chairs to monitor that). OTOH, this thread seems
to indicate that the people who're interested in the RWSG
won't be able to resist nit-picking (but sure what's new,
we do that kind of thing all the time;-)

To give an example: whether to make auth48 discussions
public seems like a fine topic for the RWSG. Exactly how
that might be done seems best left to the RPC and I'm
sure they'll co-ordinate on that with the IESG, IRSG and
ISE, and that people will yell as needed if that all goes
wrong (it won't). But I don't think RSWG nor IETF
participants need try design the details for how to make
auth48 discussion public.

Cheers,
S.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 3 Mar 2022 00:30:38 +0100

On 3. Mar 2022, at 00:23, Stephen Farrell <[email-masked]> wrote:
> nit-picking
> RPC procedures

… indeed needs to be avoided.

However, a continuous improvement process lives off stakeholder input, and I hope rfc-interest will stay a lively forum where we make our observations know.
The separation of the lists will ensure we don’t mistake these observations with a call for action for new RS** procedures.

> But I don't think RSWG nor IETF

No.  There has been a good suggestion by the IESG, and RPC can now take it from there.

Grüße, Carsten

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 3 Mar 2022 09:14:36 +0900

Hello Joel, others,

> not match what I thought we agreed.

That should indeed not be what's going to happen.

But there will be some exceptions, or borderline cases, and some of them 
may make sense. In particular:

- It may be a good idea if the RSWG starts out with one or a few
   "low hanging fruit" to get a feel for the process. Such "low
   hanging fruit" will tend to be tactical rather than strategic.

- For big, serious policy items, it may be difficult to get any
   consensus without also hashing out quite a few of the minor details.

- For some somewhat minor things that require coordination between the
   RPC, the streams, and the LLC, it may be easier to discuss them in
   the RSWG and write them down as an RFC even if strictly speaking,
   they are more tactical than strategic.

Regards,   Martin.

>>      > I thought about this a bit, and it's not immediately obvious to 
>> me that
>>      > procedures for AUTH48 handling are under the purview of the RSWG.
>>
>>      > could see an argument being made that they are under the 
>> purview of the
>>      > individual streams. There are already minor differences between 
>> the
>>      > streams, for example, the IRSG is in the loop for AUTH48 
>> exchanges or
>>      > the IRTF stream, but the IESG is not for the IETF stream.
>>
>>      > It's true that so far, all streams have used - more or less, 
>> see above
>>      > - the same process for handling AUTH48 processing. If that is 
>> intended
>>      > to be one of the invariants of the RFC series, I agree that any 
>> changes
>>      > would be under the purview of the RSWG, and any changes would 
>> then also
>>      > apply to all streams.
>>
>>      > But I could also see a future where one stream would want to 
>> revise how
>>      > AUTH48 should be handled for their documents. If this is 
>> something we
>>      > would like to allow - and personally (with no hats) I think 
>> that could
>>      > be attractive - then I don't see how this could be under the 
>> purview of
>>      > the RSWG, given that they are setting policies for the series 
>> (but not
>>      > the individual streams).
>>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 2 Mar 2022 16:14:48 -0800

> The details of which mailing lists and/or version management systems

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.

-- Christian Huitema

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Mar 2022 20:10:40 -0500

--On Wednesday, March 2, 2022 16:14 -0800 Christian Huitema
<[email-masked]> 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

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

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 3 Mar 2022 07:15:04 +0100

I am not aware of backroom dealings for non-editorial changes
during AUTH48. Examples would be useful to start having a more
educated opinion.

I do not think we should or could expect for parties currently
not involved in the AUTH48 process to start acting in the future as
additional accountable watchdogs just because we make AUTH48 communications
public. In the absense of knowing any specific examples, i can
only imagine that such an interest watchdog party might happen
if the IETF approved last draft was a very tough compromise and
a non-author party has severe concerns about abuse of AUTH48.

But in any such case i imagine that it should already be possible
to escalate such a situation after publication of the RFC and
demand for it to be taken down ("this RFC does not match functionally
the last draft and this AUTH48 change should have been IESG/WG discussed...")
If such a process is not well defined, then i think its better to do that
than to expect additional process for AUTH48. E.g.: 1 month of
"conditional publishing" of RFC in which time any such concerns
can be raised (non-editorial change from last draft during AUTH48).

That said, i am all for a real-time publically accessible
stream of AUTH48 communications. I just don't think we should
expect it to be used by our processes for anything but a)
openness and curiosity and b) reference reading for when the AUTH48
process does result in notification of IETF/WG for a required
change beyond AUTH48 purview.

Cheers
    Toerless

On Wed, Mar 02, 2022 at 04:14:48PM -0800, Christian Huitema wrote:
> 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.
> 
> -- Christian Huitema
> 
> 

-- 
---
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 3 Mar 2022 07:24:49 +0100

On 3. Mar 2022, at 07:15, Toerless Eckert <[email-masked]> wrote:
> during AUTH48.

Of course not. That is the point of backroom dealings!

More seriously, there is a continuum here, and transparency could help keeping everyone subtly more honest.

But I’m really not so concerned about backroom deals, but simply with the lack of breadth of the small group finishing the AUTH48.
Watching some AUTH48 processes from the sidelines and not understanding WHY a vexing change was made can be frustrating.
These can be editorial mistakes that come back to haunt.
Lack of breadth can also lead to actual technical errors creeping in — there again is a continuum for these.
Often, the lack of breadth also leads to longer resolution times, where the actual expert on a question might just have chimed in at the right time.

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 3 Mar 2022 07:44:19 +0100

Thanks, Carsten

What you describe would be a much bigger problem than what i imagined.
Like "we don't catch issues in WG, we don't catch issues in AD/IETF/IESG
review... they end up in AUTH48".

But then it sounds like you'd suggest that it's not only public
visibility but also public input that may be encouraged in the AUTH48
process in your view ? Even when not solicited from current AUTH48
actors. ?? Or a hard ask for authors to be responsible to quicker
escalate anything they can't or shouldn't attempt to do with just
authors/rfc-editors to the WG or other entities.

Let me rephrase: How would you describe the responsibitiles and
accountabilities to improve the process ?

"Make it public and let them come" ?

("All the planning charts and demolition orders have been on display at your local planning department...")

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 3 Mar 2022 07:51:46 +0100

> "Make it public and let them come" ?

Yes.
Those who truly care about an RFC-to-be are likely to come if we don’t make access too onerous.

> ("All the planning charts and demolition orders have been on display at your local planning department…")

Yes, but the first thing to alert you is the status change on the I-D.
You have subscribed to the status changes, no?

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 3 Mar 2022 08:53:12 +0100

> Those who truly care about an RFC-to-be are likely to come if we don’t make access too onerous.

Not necessarily those who might have the best input though.

Aka: this can IMHO only be a secondary add-on option and
must not replace some primary responsibility of authors/AD/shepherd/rfc-editor
to alert the right expert/groups from whom to explicitly seek
input if/when such a situation arises during AUTH48.

> You have subscribed to the status changes, no?

I am not aware of any status changes during auth48 to be publically available.
But lets assume we would add that.

Which publically available status change notification system are you
referring to ? All events on planet earth, the just slightly less
poluted i-d-announce mailing list or something more specific i can
easily subscribe to. I am not aware of the latter.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 3 Mar 2022 09:06:26 +0100

> input if/when such a situation arises during AUTH48.

Processes are much easier to design if you know everyone will always do their tasks perfectly and on time.
(In Software Engineering, we call this process confabulation.)

Yes, public AUTH48 is a small additional safety net, and a very thin one.

> But lets assume we would add that.

During AUTH48 — yes, you have to follow the list.

> referring to ?

1 Go to https://datatracker.ietf.org/wg/core/documents/ (for a WG of your choice)
2 Scroll to the end
3 Click “Subscribe to changes” (or “Change subscription”)
4 Fill in the form (“All changes”).  Submit.
5 Profit from the magically improved situational awareness you now have achieved.

(You can also get an atom feed.)

> All events on planet earth, the just slightly less

See above.

I don’t know how to subscribe to AD-sponsored documents, though.

Grüße, Carsten

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 3 Mar 2022 09:21:54 +0100

> Yes, public AUTH48 is a small additional safety net, and a very thin one.

Right. Thats how it should be described/sold.

> During AUTH48 — yes, you have to follow the list.

Which would depend on someone making an issue public during AUTH48.
Which  we seem to believe may not be sufficient. 

> 5 Profit from the magically improved situational awareness you now have achieved.

Thanks!

> I don’t know how to subscribe to AD-sponsored documents, though.

Actually seems to be possible (luckily) to enable for non-wg docs, like
draft-iab-rfcefdp-rfced-model, at least i found a "Track" thingy to click
on for it just on the datatracker page for the doc itself. Let's see if it works.

(i was actually looking long on the page to find something and didn't, and
 only after you sent your explanation did i find the "track" thingy on the
 documents page, so i am sure that features you're not made aware of first
 really don't exist ;-)

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Jean Mahoney <[email-masked]>
Date: Thu, 3 Mar 2022 10:29:54 -0600

Hi all,

Please note that the RPC requests review and approval from a stream 
manager of any change made during AUTH48 that is beyond editorial. This 
policy may be found on the rfc-editor.org website [1] [2] and also in 
each email message that starts AUTH48:

    We will ask a stream manager to review and approve any changes that seem
    beyond editorial in nature, e.g., addition of new text, deletion of text,
    and technical changes.  Information about stream managers can be found in
    the FAQ.  Editorial changes do not require approval from a stream manager.

Best regards,

Jean Mahoney
RPC Project Manager

[1] https://www.rfc-editor.org/pubprocess/auth48/
[2] https://www.rfc-editor.org/faq/#streammanagers

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Mar 2022 14:15:21 -0500

> Of course not. That is the point of backroom dealings!

at least, if you are any good at them.

    > keeping everyone subtly more honest.

I would say it differently.

People not involved any a specific AUTH48 can't be sure what horse trading
may have occurred during the editing, or who initiated it.
ADs might be able to say that they have never seen any backroom dealings, and
specific authors may agree for specific documents, but suspicious could still remain.

Having a public audit trail just makes everyone feel happy.

    > But I’m really not so concerned about backroom deals, but simply with
    > the lack of breadth of the small group finishing the AUTH48.

Agreed.

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Mar 2022 22:07:00 -0500

--On Thursday, March 3, 2022 14:15 -0500 Michael Richardson
<[email-masked]> wrote:

>...
>     > More seriously, there is a continuum here, and
> transparency could help     > keeping everyone subtly more
> honest.
> 
> People not involved any a specific AUTH48 can't be sure what
> horse trading may have occurred during the editing, or who
> initiated it. ADs might be able to say that they have never
> seen any backroom dealings, and specific authors may agree for
> specific documents, but suspicious could still remain.
> 

>     > But I'm really not so concerned about backroom deals,
> but simply with     > the lack of breadth of the small group
> finishing the AUTH48.
> 
> Agreed.

It once again feels to me as if two separate concerns are being
conflated and that the above identifies them.

Concern 1: There is a suspicion that something nefarious is
going on.
	Plausible solution: Make the correspondence public
	either in real time or on request later. (Not a perfect
	solution, see "observation" below.)

Concern 2: The AUTH48 reviewers lack breadth or are sufficiently
invested in one vision of the document to not be able to
reliably make good critical decisions consistent with consensus
of the Stream/ Approving body.   Using the IETF Stream as an
example, with no malice at all, inconsistency between the views
of the community and those of the authors and IESG could be
another part of this concern.
	Plausible solution:  Figure out a better way to allow
	broader review immediately pre-publication. 

Observation: those two concerns are not mutually exclusive and
neither are the plausible solutions.  And the weakness in the
proposed solution to Concern 1 is that, if there is information
about the reason to make one seemingly equivalent choice over
another that should not be generally discussed or, if someone
actually and intentionally wanted to do something nefarious, the
proposal would allow either to be kept out of the public record,
with no way to tell them apart.   Because of the first case,
forcing all AUTH48 correspondence to be public might easily
result in lower-quality documents.

    best,
    john

---

From: Lars Eggert <[email-masked]>
Date: Fri, 4 Mar 2022 09:48:28 +0200

Hi,

neither of the two concerns below motivated the proposal by the IESG to make the AUTH48 discussions public. The motivation was to further increase transparency of our processes.

> Concern 1: There is a suspicion that something nefarious is

The IESG doesn't have this suspicion, and I'd be surprised to learn that a significant part of the community has this suspicion, given that is extremely rare for any individual AUTH48 to result in any significant discussion.

> 	solution, see "observation" below.)

The motivation for making AUTH48 discussions public is solely that AUTH48 is AFAICT the only remaining step in the standardization process where private discussions are still being held (albeit only on editorial questions), and the IESG wanted to further increase transparency here.

> another part of this concern.

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

> 	broader review immediately pre-publication.

This is explicitly a non-goal. The conversation in AUTH48 is intended to remain between the authors/editors and the RPC, with ADs in the loop. It is not intended to morph into some sort of post-approval community last call.

Thanks,
Lars

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Mar 2022 13:46:18 -0500

Lars, thanks...

--On Friday, March 4, 2022 09:48 +0200 Lars Eggert
<[email-masked]> wrote:

> Hi,
> 
> neither of the two concerns below motivated the proposal by
> the IESG to make the AUTH48 discussions public. The motivation
> was to further increase transparency of our processes.

And, in case it has not been clear, I appreciate that.  I just
don't think that type of transparency alone and as proposed is
really helpful for those people with concerns about a particular
document because of the S/N problems it implies.    The concerns
I identified were raised in discussions on this thread, not in
what the IESG proposed.  More below.

> The IESG doesn't have this suspicion, and I'd be surprised to
> learn that a significant part of the community has this
> suspicion, given that is extremely rare for any individual
> AUTH48 to result in any significant discussion.

Again, referring to the list discussion and not to the IESG
announcement/ proposal, I have definitely seen that concern
raised.  Do I think a significant part of the community has that
suspicion?  Personally, I have doubts that a significant part of
the community cares about these issues at all? I would not be
surprised if a significant part of the community had even heard
of AUTH48, much less had a clue about what it was about, before
this discussion broke out (those who are not on these two lists
devoted to the RFC Editor Function probably still don't).

That said -- and it is definitely a separate question -- over
the years I have seen multiple cases in which decisions have
been made during AUTH48 about WG documents that arguably should
have been thrown back to the WGs (even if only for ratification)
and where that was not done.  In those cases, there have almost
always been reasonable and honest differences of opinion about
whether the WG would have anything useful to say if asked and
whether the added delay would be worth the trouble.  Practical
improvements in the transparency of such decisions would
definitely be welcome (see below).

Going further afield, something similar could be said about
bouncing documents back to a WG (not just document
authors/submitters) rather than making decisions during IESG
review and decision-making after Last Calls are completed.

> The motivation for making AUTH48 discussions public is solely
> that AUTH48 is AFAICT the only remaining step in the
> standardization process where private discussions are still
> being held (albeit only on editorial questions), and the IESG
> wanted to further increase transparency here.

Entirely worthwhile, but see below.

>> Concern 2: The AUTH48 reviewers lack breadth or are
>> sufficiently invested in one vision of the document to not be
>> able to reliably make good critical decisions consistent with
>> consensus of the Stream/ Approving body.   Using the IETF
>> Stream as an example, with no malice at all, inconsistency
>> between the views of the community and those of the authors
>> and IESG could be another part of this concern.
 
> 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).

> This is explicitly a non-goal. The conversation in AUTH48 is
> intended to remain between the authors/editors and the RPC,
> with ADs in the loop. It is not intended to morph into some
> sort of post-approval community last call.

As more people have been added to the distribution of AUTH48
interactions, it seems to me that we are already past
authors/editors, the RPC, and responsible ADs (rather than the
whole IESG) in the conversation/loop.  Shepherds have been added
and sometimes people who have made comments during Last Call or
IESG review have been added.   Even the procedural notes to
which Jean Mahoney pointed us yesterday require "steam manager"
review of certain types of changes.  This might be another issue
with definitions in the model document but my understanding is
the "stream manager" does not differ from document to document,
so that presumably points to the IESG or someone the IESG
appoints  to that role on a relatively long-term basis (not
per-document).

So, part of my comment, the IESG's goals aside, is that we are
already on the slippery slope past authors/editors and an AD.

If I have any disagreement with what the IESG proposes in the
name of simple transparency (as you suggest above), it is more
about goals than about mechanisms.  I think that the goal of
establishing more formal/symbolic transparency (and I don't
intend either of those terms pejoratively) is always good and
especially good when AUTH48 is, as you point out, the only part
of the standardization process where private discussions still
occur [1].  That is consistent with what I have observed of the
list discussion: I've seen proposals about how to better tune
what should be done.  However, all of them have been targeted to
other goals or criteria.  I'm also seen questions about impact
on other Streams and about timing, but I don't think anyone has
said either "bad idea in any form" or "that is a bad goal" to
the IETF proposal

So, please take my comments and attempt to summarize other
issues/goals (with which, in case it wasn't clear, I don't
necessarily agree), not as "your goals are bad" or "don't do
this".  They are about whether you have (accidentally?) exposed
some other problems that should be addressed and goals that
should be in your queue for discussion at some point.  In
particular, we know that AUTH48 sometimes addresses issues that
are not strictly editorial.  If that were not the case, there
would be no need for the RPC procedural statements or AD
involvement.  I don't think it is either feasible or desirable
to try to change that, but it involves a question the IESG
should ask, almost certainly in conjunction with the RSWG.  And,
IMO more important, if even marginally non-editorial decisions
are being made after the IESG signs off on a document, do we
have enough safeguards in place to ensure that those decisions
are made consistent with what they community thought it was
agreeing to during Last Call or that were covered in a final,
post-approval, draft posted by the authors/editor (and that
everyone feels confident about that)?  The answer may well be
"yes" (or nearly so), but I think your setting goals for greater
transparency suggests that, sooner or later, those questions
should be asked.

thanks,
  john

[1] I don't quite believe that, but it is part of separate
discussion we might have at another time.

---

From: Christian Huitema <[email-masked]>
Date: Fri, 4 Mar 2022 12:02:22 -0800

> 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 Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Mar 2022 12:10:15 -0800

On Fri, Mar 4, 2022 at 12:02 PM Christian Huitema <[email-masked]>
wrote:

> 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.
>
Without taking a position on transparency and appropriateness, I would say
that most drafts I am involved with have had some of this in the AUTH48
stage, and semantic changes are pretty common (though cleared with the AD
and usually the WG).

-Ekr

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Fri, 4 Mar 2022 21:25:58 +0100

Christian,

On 04.03.22 21:02, Christian Huitema wrote:
> "please remove before publication". But in my mind, rewriting 
> paragraphs does not belong there.

Given the dearth of incidents when output of a working group so 
surprised members when it became an RFC, I'd argue that'd be a bad trade 
off against the readability that the RPC helps us gain.  And yes, there 
was ONE incident in the early 1990s.  We've discussed it before.  In 
fact we discussed it then.  That makes me wonder what all the fuss is about.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Mar 2022 16:14:26 -0500

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

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 05 Mar 2022 15:17:48 -0500

> The IESG doesn't have this suspicion, and I'd be surprised to learn
    > that a significant part of the community has this suspicion, given that
    > is extremely rare for any individual AUTH48 to result in any
    > significant discussion.

Of course not.
The IESG knows what goes on during AUTH48.