Subject: Public archival of AUTH48 communications

From: The IESG <[email-masked]>
Date: Thu, 24 Feb 2022 14:24:19 -0800

The IETF prides itself on its open process and transparent 
communication, with one of our core principles being our commitment to 
making all materials related to our standards process and other 
activities publicly available. 

For a document undergoing publication within the IETF Stream, most of 
its history can be traced by exploring the mail archive - from the first 
submission, to Last Call comments, to IESG evaluation. However, once the 
document enters the RFC Editor queue, the communication between authors 
and RFC Production Center (RPC) is only visible to a specific set of 
people: RFC editors, authors, the responsible ADs and WG chairs (when 
applicable). 

In order to increase transparency during the final stages of document 
editing, the IESG, IAB, ISE, IRSG, Temporary RFC Series Project Manager, 
RPC, and Tools team are considering allowing anyone to search and read 
AUTH48 conversations about specific documents (or clusters of 
documents). It is not a goal to actively involve more people in the 
conversation between authors and RFC editors.

Our proposal: to set up a public mailing list of AUTH48 conversations, 
for archival purposes only, i.e., read-only. The RFC editors, when 
initiating the conversation with the authors will CC this mailing list. 
All further responses usually maintain the CC addresses, and as a 
consequence will be archived in the mailing list archive. 

All AUTH48 discussions of all documents will be archived on the same 
mailing list. Searches and filtering will be available based on the 
mails’ content and metadata, including draft name, RFC-to-be number, 
cluster number, sender, and date.

Opt out: the authors and RFC editors are able to opt out from archival, 
by removing the mailing list from the CC. Although we don’t envision 
that this will be necessary often, there may be cases where sensitive 
information needs to be shared.

The initial AUTH48 mail from the RFC Editor will also include text about 
public archival, to make sure authors are aware. With this announcement, 
the IESG wants to inform the community and read feedback before we set 
anything up. Please send any comment to [email-masked] or reply to this 
thread by 24 March 2022.

Francesca Palombini for the IESG

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Feb 2022 14:59:39 -0800

This seems reasonable to me. However, I do have one logistical question. We
are increasingly seeing some of this discussion on Github. Would that also
be archived and if so how?

-Ekr

On Thu, Feb 24, 2022 at 2:25 PM The IESG <[email-masked]> wrote:

> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Feb 2022 13:42:59 +1300

> Our proposal: to set up a public mailing list of AUTH48 conversations, 

Please confirm that this is only for IETF stream documents so far. The IESG
can't take decisions that cover the other streams; the mechanisms for RFC
Editor policy that covers all streams are currently in Last Call and it
would be strange (to say the least) to make this decision for all streams
now rather then when the new mechanisms are in place. That would in effect
preempt and undercut the new mechanisms just before they start.

I would probably support this proposal strongly if it was brought to the
future RSWG. But I definitely object to preempting that discussion.

Perhaps a fixed term experiment and a promise to bring the results of
that experiment to the RSWG as a policy proposal would be the way to go?

Regards
    Brian Carpenter

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 24 Feb 2022 17:27:56 -0800

Hi, all,

Overall, this seems reasonable, HOWEVER, I would like to ensure that this isn’t the only way authors know about it.

I.e., *each* AUTH48 message should come with a prominent notice that the exchange is being archived and instructions to opt-out.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Feb 24, 2022, at 2:24 PM, The IESG <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 25 Feb 2022 02:44:25 +0100

On 25. Feb 2022, at 01:42, Brian E Carpenter <[email-masked]> wrote:
> Please confirm that this is only for IETF stream documents so far.

We already discussed this in the IRSG and would like to join.

My personal take: We have enough ossification of RFC-related matters; I don’t think we need to push this one up to 2026.
The RSWG can tweak this when they get to power.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Feb 2022 15:06:59 +1300

On 25-Feb-22 14:44, Carsten Bormann wrote:
> My personal take: We have enough ossification of RFC-related matters; I 
don’t think we need to push this one up to 2026.
> The RSWG can tweak this when they get to power.

No, that assumes a fait accompli and that is very much against the spirit 
of community-approved RFC policy which is what people have been demanding 
for several years. Running an experiment now is fine, declaring a policy isn't.

I would expect the RSWG/RSAB to be operational a month or two from now; the last calls expire on March 7.

     Brian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 24 Feb 2022 18:12:17 -0800

> the last calls expire on March 7.

I concur with Brian and I appreciate him catching this.

-Ekr

> rfc-interest mailing list
> [email-masked]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 25 Feb 2022 08:33:29 +0000

> On 25 Feb 2022, at 00:42, Brian E Carpenter <[email-masked]> wrote:
> 
> can't take decisions that cover the other streams;

The IRSG discussed this for the IRTF stream, and agreed to join with the proposal.

The IESG has been very open in their communication and discussion with the other streams about this.

Colin Perkins
IRTF Chair

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Feb 2022 08:38:14 -0000

> From: rfc-interest <[email-masked]> On Behalf Of
Colin Perkins
> Sent: 25 February 2022 08:33
>

Indeed. I can confirm that the ISE was consulted about whether to apply this
to the Independent Stream, and I thought it a useful measure.
Eliot, as the new ISE, can confirm whether he wants to continue with that or
not.

Cheers,
Adrian

---

From: Ted Hardie <[email-masked]>
Date: Fri, 25 Feb 2022 08:50:59 +0000

Thanks for considering the transparency question seriously.  I
believe, however, that you are missing a more obvious implementation:
cc'ing the working group mailing lists for AUTH48 discussions.  That
keeps the information related to a single document in a common place,
which makes it easier to actually follow the threads of work than it
would be if it were in a dedicated list.  While your proposal is
publicly archived, that approach would require any interested
individual to grovel through the archives periodically to see if there
were anything of interest, which makes it easy to miss the discussions
and more difficult to link back to the working group discussions.

You may be concerned that this approach would lead to the working
groups' members jumping into the last call discussions, since those
lists are not read only.  You can avoid them doing so directly by
channeling the AUTH48 mail to the mailing through a send-only address
which does not receive mail.*  That would not stop a mailing list
member from reaching out to one of the parties individually, but your
proposed implementation doesn't stop that either.

If an IETF document does not have a working group (as an AD-sponsored
document might not), then the mail could go to the area list.

Since this approach would be specific to the IETF, it would allow
later tweaks to be done directly by the IESG, without necessarily
coordinating them with other streams which might have different needs.

regards,

Ted Hardie

*Passing them through a send-only address also potentially gives you a
step in which to process them so as to elide specific information that
you might not want to share early, such as the RFC number or links to
the RFCs-to-be.  If you do not choose this implementation, you may
still want to consider whether those details belong in the archived
list, since references to the RFC number may otherwise appear in
advance of actual publication.  Since some AUTH48 issues take a fair
amount of time to resolve, that can actually result in a fair amount
of cruft.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 25 Feb 2022 11:15:10 +0100

On 2022-02-25, at 09:50, Ted Hardie <[email-masked]> wrote:
> 
> references to the RFC number may otherwise appear in
> advance of actual publication

Got the below chat message right after 9175 was published.
So these links already leak to google…
(No idea what or whether to do about this.)

(Of course, many IETFers rsync the RFC editor, so they have local copies anyway.)

> cc'ing the working group mailing lists for AUTH48 discussions

Of course, authors can use the protected nature of the AUTH48 exchanges to nudge the draft a little away from what the WG wanted.  The chairs and ADs are supposed to watch this, but they may not be aware of specific strong positions of (or deals made with) individuals on the WG list.  So CCing WGs would help keeping authors honest a bit more…
It also would draw in loud dissenters from the WG who will then create unceasing discussion threads, trying to win by attrition.

And WG lists are often indexed by search engines, so that might contribute to the above noted search engine effect.

Re trying to keep the RFC-to-be (draft RFC) secret:
It is less useful to follow the AUTH48 discussions when you can’t access the draft RFC.
(It is difficult enough to keep track of what changed in a new draft RFC; I’m actually rsyncing with timestamped backups to be able to follow the discussions.  These should be on a git repo...)

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Fri, 25 Feb 2022 14:19:02 +0100

> Eliot, as the new ISE, can confirm whether he wants to continue with that or

And I haven't had an opportunity to consider the matter just yet.  If 
you have thoughts, feel free to send them my way.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Feb 2022 09:06:29 -0500

{trimmed the -announce out. Not sure what list this discussion should occur on}

Ted Hardie <[email-masked]> wrote:
    > Thanks for considering the transparency question seriously.  I believe,
    > however, that you are missing a more obvious implementation: cc'ing the
    > working group mailing lists for AUTH48 discussions.  That keeps the
    > information related to a single document in a common place, which makes
    > it easier to actually follow the threads of work than it would be if it
    > were in a dedicated list.

This works for me.

AD sponsored documents do not necessarily have lists, but I don't think the
two solutions are mutually exclusive.

    > which does not receive mail.* That would not stop a mailing list member
    > from reaching out to one of the parties individually, but your proposed
    > implementation doesn't stop that either.

I also have the concern that the RFC-editor could get confused about comments, or
that the thread could wind up re-litigating something that already reached
rough consensus.    I think that this is the experiement worth doing though.

With this send-only address on the list, we still have the problem of authors
replying, don't we?  They write to the ML, and then people argue with them.
(And the authors, probably on the list, get yet another copy of the email. Oh well.)

I know that the RFC-editor has been using lists cXXXX when dealing with
clusters.  I thought that this was a good thing, and maybe that could help
solve the technical challenges.

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

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Fri, 25 Feb 2022 14:10:18 +0000

I am strongly in favor of cc'ing the working group mailing lists for AUTH48 discussions. I've been in too many working groups where a document went into a black hole for months as far as the WG was concerned, after it went to the RFC editor and finally made it through "auth48". And yes, there have been times when subtle changes happened that I felt  at the time probably shouldn't have.

	Tony

On 2/25/2022, 3:51 AM, "rfc-interest on behalf of Ted Hardie" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Feb 2022 06:18:37 -0800

While I think transparency is good, I think sending them through the WG
list would be a mistake.

In many cases there is a tremendous amount of back and forth about small
details that I would prefer not to be bothered with for every WG list I am
on.

I don't object to a separate list that WG members could subscribe to.

-Ekr

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 25 Feb 2022 14:36:34 +0000

Hey

> I don't object to a separate list that WG members could subscribe to.

+1.

Before becoming a chair, all I encountered was a black hole. Now as a chair
I see the interactions and it is quite insightful, while at the same time
sometimes being none of my business (in a responsibility sense).

In the QUIC WG, most of our business is done on GitHub. The mailing list
remains fairly quiet and the signal to noise ratio is good. Reflecting a
full auth 48 discourse onto the QUIC list would be a negative in my
opinion. A single email to notify people about the fact that auth48 has
started, and where to go and subscribe, would be good though.

Cheers
Lucas

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Feb 2022 14:56:39 +0000

As others have said, thanks for working to increase the transparency of IETF processes.

I have seen both sides of the issues brought up by Lucas, Eric, and Ted.  As a WG chair, I tried to be diligent in bringing things back to the WG when it seemed necessary, but it’s not great that this depends on the whims and views of one person. On the other hand, very few people really want to follow, let alone participate in, detailed arguments about the Chicago Manual of Style.

I don’t have a proposal, just confirming the point raised by others.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 25 Feb 2022 15:14:29 +0000

On Fri, Feb 25, 2022 at 2:19 PM Eric Rescorla <[email-masked]> wrote:
>
> While I think transparency is good, I think sending them through the WG list would be a mistake.
>
> In many cases there is a tremendous amount of back and forth about small details that I would prefer not to be bothered with for every WG list I am on.
>
This would work for me, and I think it is a nice parallel to the way
the GH comment streams are set up in the working groups that use them.
There is a separate list you can subscribe to, and it's your choice as
to whether to intermingle that in your folders with the main WG list.
I personally keep them nested under the main list, and I'd do the same
here, but I like the flexibility this proposal offers.

regards,

Ted Hardie

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 25 Feb 2022 09:37:45 -0600

> The RSWG can tweak this when they get to power.

+1

Behcet

---

From: Francesca Palombini <[email-masked]>
Date: Fri, 25 Feb 2022 15:43:07 +0000

Hi all,

I am monitoring the discussion, listening to the feedback, and hope to answer to all comments later on.

Ted: Just a clarification question. As a separate mailing list was also the proposal, I am trying to understand the difference with Ekr’s suggestion.
If I understand correctly, the difference with what Ekr is suggesting is that there would be one AUTH48 mailing list for each AUTH48 conversation, is that the idea? This was discussed, but the same sort of subscribing and filtering can be achieved locally even with one single list, and would require less tooling and RPC change, so I am not sure I see the interest of setting it up that way.

Thanks,
Francesca

From: iesg <[email-masked]> on behalf of Ted Hardie <[email-masked]>
Date: Friday, 25 February 2022 at 16:15
To: Eric Rescorla <[email-masked]>
Cc: Working Group Chairs <[email-masked]>, [email-masked] <[email-masked]>, IETF <[email-masked]>, RFC Interest <[email-masked]>, IESG <[email-masked]>, [email-masked] <[email-masked]>, IETF Announcement List <[email-masked]>
Subject: Re: [rfc-i] Public archival of AUTH48 communications

regards,

Ted Hardie

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 25 Feb 2022 16:46:43 +0100

> I don't object to a separate list that WG members could subscribe to.

Doubles the number of lists I need to subscribe to.

I think I’d prefer the AUTH48 list.

(But I do understand the preference here will depend on whether you employ a mail client that has functionality for handling non-trivial mail sources.)

Grüße, Carsten

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 25 Feb 2022 16:58:41 +0100

Just one small comment below.

> On 25. Feb 2022, at 16:46, Carsten Bormann <[email-masked]> wrote:
> 

But you don’t have to subscribe to any new list. Those people who get the AUTH48 mails today would still get them directly - so now change needed. The intend is actually that people won’t subscribe to the list but only can use the archives to look up anything if needed. Of course we can’t stop anybody from subscribing but that is really not the intention here.

Mirja

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 25 Feb 2022 08:25:25 -0800

Why are we trying to do something with email that might be better handled with a more semantically rich technology, e.g., an issue tracker?

That way, the info is organized and can be cross-linked without needing copies.

Joe

—

> On Feb 25, 2022, at 7:46 AM, Carsten Bormann <[email-masked]> wrote:
>

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Fri, 25 Feb 2022 16:37:23 +0000

Perhaps there should be an auth48 mailing list per working group? It would be used for all auth48 interactions associated with the docs for that WG. When a doc from a WG enters auth48, a note would be sent to the WG indicating the location of that working group mailing list. Non-WG auth48 interactions could use a single non-WG mailing list.

I think this would satisfy both Ted's and Ekr's preferences. (Mine too. :) )

Advantages:

*) Separates the auth48 traffic away from the working group.
*) Separates the auth48 traffic for one WG from all other auth48 traffic.
*) Reduces the number of mailing lists that need to be managed.
*) The mailing list could be moderated to only allow the auth48 authors (and RPC) to post to it, and only while their documents are in that state.
*) Allows someone who wants to follow the auth48 traffic for that WG to do so.
*) Doesn't force someone (who is interested in following the auth48 traffic for a given set of WGs) from seeing the back and forth for ALL WGs.

I think the last two bullets are particularly important.

	Tony

On 2/25/2022, 10:15 AM, "rfc-interest on behalf of Ted Hardie" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Feb 2022 08:58:45 -0800

On Fri, Feb 25, 2022 at 7:43 AM Francesca Palombini <
[email-masked]> wrote:

> Ted: Just a clarification question. As a separate mailing list was also
> the proposal, I am trying to understand the difference with Ekr’s
> suggestion.
>
> If I understand correctly, the difference with what Ekr is suggesting is
> that there would be one AUTH48 mailing list for each AUTH48 conversation,
> is that the idea? This was discussed, but the same sort of subscribing and
> filtering can be achieved locally even with one single list, and would
> require less tooling and RPC change, so I am not sure I see the interest of
> setting it up that way.
>

No, I'm suggesting that it doesn't go to the main WG mailing list. I am
indifferent to whether it is a single list for all AUTH48 communications
for a WG or one for each RFC.

What I don't think we should do is just change the setup for each WG
mailing list so that suddenly everyone gets the AUTH48 stuff whether they
care or not, thus forcing most of those people to set up filters to filter
it out.

-Ekr

>
>
> Thanks,
> Francesca
>
>
>
> *From: *iesg <[email-masked]> on behalf of Ted Hardie <
> [email-masked]>
> *Date: *Friday, 25 February 2022 at 16:15
> *To: *Eric Rescorla <[email-masked]>
> *Cc: *Working Group Chairs <[email-masked]>, [email-masked] <
> [email-masked]>, IETF <[email-masked]>, RFC Interest <
> [email-masked]>, IESG <[email-masked]>, [email-masked]
> <[email-masked]>, IETF Announcement List <[email-masked]>
> *Subject: *Re: [rfc-i] Public archival of AUTH48 communications
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 25 Feb 2022 17:09:08 +0000

On Fri, Feb 25, 2022 at 3:43 PM Francesca Palombini <
[email-masked]> wrote:

> is that the idea?

I believe it would be for each working group.  So if you are a member of
the QUIC working group, as an example, you can choose to subscribe to the
AUTH48 list for QUIC's working group drafts.  If you do, you will see (but
not be able to respond directly) to the related traffic.

For those working groups that use github, there is already a method to
subscribe to a separate mailing list that receives the github repo
traffic.  You can decide whether to follow that by tracking it on github,
by following the mailing list, or not at all.  Similarly, if you subscribe
to that list you can decide whether to intermingle the messages with the
regular working group email or keep it separate on a working-group by
working group basis.

> This was discussed, but the same sort of subscribing and filtering can be
> achieved locally even with one single list,
>

You're asking a whole bunch of people to configure a whole bunch of filters
to get functionality that mirrors functionality we do all the time on the
IETF side (with draft-authors style lists).  I'm not sure that I understand
why that's a big win.

regards,

Ted

> and would require less tooling and RPC change, so I am not sure I see the
> interest of setting it up that way.
>
>
>
> Thanks,
> Francesca
>
>
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 25 Feb 2022 17:12:03 +0000

> care or not, thus forcing most of those people to set up filters to filter

I see I misrepresented you in my mail to Francesca.  I thought you were
proposing to do it by WG, rather than by draft.  To me, that's the natural
unit of review here.  That's why I initially suggested using the WG mailing
list, and why I would be fine with setting up a per WG AUTH48 list as a
separate list.

That is, in any case, what I now suggest.

regards,

Ted Hardie

>> [email-masked]>, IESG <[email-masked]>,
>> [email-masked] <[email-masked]>, IETF Announcement List <
>> [email-masked]>
>> > In many cases there is a tremendous amount of back and forth about
>> small details that I would prefer not to be bothered with for every WG list
>> I am on.
>> >

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Feb 2022 09:32:21 -0800

On Fri, Feb 25, 2022 at 9:12 AM Ted Hardie <[email-masked]> wrote:

> proposing to do it by WG, rather than by draft.
>

I'm not sure you misrepresented me. I honestly hadn't thought through the
WG-versus-draft units.

To me, that's the natural unit of review here.  That's why I initially
> suggested using the WG mailing list, and why I would be fine with setting
> up a per WG AUTH48 list as a separate list.
>

This sounds like a good plan. I wonder if the new subscription interface
could easily give people the choice to make that decision en masse.

-Ekr

>>> [email-masked] <[email-masked]>, IETF Announcement List
>>> <[email-masked]>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 25 Feb 2022 18:35:32 +0100

On 2022-02-25, at 16:58, Mirja Kuehlewind <[email-masked]> wrote:
> But you don’t have to subscribe to any new list.

I’d have to so I can make timely use of the transparency functionality proposed.
(I’d actually use the IETF’s IMAP server directly instead of an SMTP subscription, but I’d still need to do this a large number of times.)

> Those people who get the AUTH48 mails today would still get them directly - so now change needed.

Understood.

> The intend is actually that people won’t subscribe to the list but only can use the archives to look up anything if needed.

After the damage is done?  Sure, that is useful, but being informed in real-time so damage can be prevented is more useful.

> Of course we can’t stop anybody from subscribing but that is really not the intention here.

It sure would be mine.

Grüße, Carsten

---

From: Larry Masinter <[email-masked]>
Date: Fri, 25 Feb 2022 10:03:25 -0800

With the move to XML and renderings of a new RFC in different formats, who is responsible for reviewing the different renderings for unintended changes in meaning? If it's the authors, I'd hope that a change in AUTH48 might offer some way to spread the burden.

FWIW
--
https://LarryMasinter.net https://interlisp.org

> -----Original Message-----
> HANSEN, TONY L
> Sent: Friday, February 25, 2022 8:37 AM
> To: Ted Hardie <[email-masked]>; Eric Rescorla <[email-masked]>
> Cc: IESG <[email-masked]>; IETF Announcement List <[email-masked]>;
> Working Group Chairs <[email-masked]>; [email-masked]; RFC
> Interest <[email-masked]>; [email-masked]; IETF
> <[email-masked]>
> Perhaps there should be an auth48 mailing list per working group? It would be
> used for all auth48 interactions associated with the docs for that WG. When a
> doc from a WG enters auth48, a note would be sent to the WG indicating the
> location of that working group mailing list. Non-WG auth48 interactions could
> use a single non-WG mailing list.
> 
> *) The mailing list could be moderated to only allow the auth48 authors (and
> RPC) to post to it, and only while their documents are in that state.
> *) Doesn't force someone (who is interested in following the auth48 traffic for
> a given set of WGs) from seeing the back and forth for ALL WGs.
> 
> On 2/25/2022, 10:15 AM, "rfc-interest on behalf of Ted Hardie" <rfc-interest-
> [email-masked] on behalf of [email-masked]> wrote:
> 
> small details that I would prefer not to be bothered with for every WG list I
> am on.
>     >

---

From: tom petch <[email-masked]>
Date: Sat, 26 Feb 2022 12:52:52 +0000

> care or not, thus forcing most of those people to set up filters to filter

Communicate, communicate, communicate.

Tell people what is happening before it happens, identify what actions 
people are likely to take and suggest how they might do take them.

The IETF failed to do this when AD comments at IESG Review started 
appearing on WG mailing lists.  I completely misunderstood the situation 
which, in hindsight, was a predictable outcome.  Seeing those comments 
has been instructive if only in helping WG members fix things so that 
the IESG do not have to, but the change was poorly managed.

Of course, as a recent analysis showed, most people are not on this list 
and so will not know of this important change.

Tom Petch

---

From: John C Klensin <[email-masked]>
Date: Sat, 26 Feb 2022 11:53:54 -0500

TL;DR comment: for those who don't like my long notes, skip to
the bullet points that make up the final paragraph - they should
tell you whether the rest is worth reading.

--On Friday, February 25, 2022 16:37 +0000 "HANSEN, TONY L"
<[email-masked]> wrote:

> Perhaps there should be an auth48 mailing list per working
> group? It would be used for all auth48 interactions associated
> with the docs for that WG. When a doc from a WG enters auth48,
> a note would be sent to the WG indicating the location of that
> working group mailing list. Non-WG auth48 interactions could
> *) The mailing list could be moderated to
> only allow the auth48 authors (and RPC) to post to it, and
> only while their documents are in that state.
> *) Allows someone who wants to follow the auth48 traffic for
that WG to
> do so.
> *) Doesn't force someone (who is interested in
> following the auth48 traffic for a given set of WGs) from
> seeing the back and forth for ALL WGs.
> 

Hi.  I have tried to review this very active discussion up to
now.  Tony's note seems --not quite arbitrarily-- to be a useful
choice on which to base a response but I want to go up a level.

First, it is hard to oppose transparency and I don't want to go
there.  I've also been concerned for years that decisions are
sometimes made during AUTH48 that affect the substantive content
of documents without people who care about those documents
having any visibility.  So I'm very glad the IESG is engaging on
the issue.  However, I wonder whether the wrong question is
being asked and suggest that much of this thread points that out.

>From my perspective, the problem is not that the AUTH48
discussions --which, as has been pointed out, are typically
about more or less fine points of style and presentation-- but
about making sure that substantive content changes are
appropriately reviewed.   In a more perfect world, we would be
able to count on ADs and WG Chairs to identify the point at
which substantive changes were being requested and either get an
intermediate I-D back to the relevant WG list or even restart a
Last Call.  That is presumably the reason why ADs, and then WG
Chairs, and then Shepherds were added to the per-document AUTH48
distributions.  That has no worked as well as I would have liked
but YMMD. If the IESG shares that concern, can we look at that
problem rather than simply appealing to transparency and, in the
process, doing things that make the IETF's S/N and substantive
technical progress to procedural work ratios even worse?

So:
(1) If we are going to do more or less what has been proposed, I
think Tony's summary of what should be done is about right, and
agree that the last two points are critical.

(2) However, if the real target is better documents and fewer
surprises about substantive changes, consider one or more of the
following other possibilities, ones that, btw, would also work
for non-WG documents without assuming that all of them are the
same:

(a) When a document goes into AUTH48, post an announcement of
that event to the Last-Call list (on the theory that final
document review is really part of the Last Call process).
Allow anyone who is so inclined to subscribe to the AUTH48
discussion for that document but with the understanding that
they are observing, not participating, and that, if they have
issues, they should raise them off-list with authors and/or ADs
as appropriate.  I don't think we need special tooling for the
latter: if this it the professional community we claim it is,
most of the people will behave almost all of the time and,
someone becomes disruptive, the IESG has more than adequate
tools for dealing with that.

(b) Instead of making a general announcement on the Last-Call
list, make a similar announcement to the WG (if any) and to
anyone who commented on that document during Last Call
(including IESG review) and thereby identified their interest.
That would reduce traffic on the Last-Call list and potential
reduce noise but would require more tooling.

(c) Decide that we don't really care about the internals of the
AUTH48 discussion process and instead treat it as much more like
a design team effort at the back end of the process.  Instead,
when a document has been signed off by everyone who now has to
sign off (or earlier at their discretion), have the RPC post
notice of availability of a final pre-publication RFC to the
Last Call list (or, in a variation on (b), to those who are
assumed to be interested).   If they have a diff readily
available between that "final" version and an initial version in
RFC (rather than I-D) format, include a link to that too.  That
is a notice, no a request for further comments.  Anyone who
objects to publication based on changes between the version
officially approved by the IESG uses the conventional appeals
process (possibly with a much shorter window, like a week or ten
days) to ask for a review based on those changes exceeding the
mandate of the AUTH48 process.  If the IESG agrees that the
appeal has merit, they (at least normally) start a new Last Call
on the revised document rather than trying to tinker within an
extension of the AUTH48 process.

Result of (c): 
* No more mailing lists.  
* No more noise due to either traffic that most people are not
interested in most of the time or to trying to extricate
important issues from a large amount of traffic that isn't.  
* Reduces, if not completely preventing, the whole community
from being drawn into debates about fine points of editorial
style.
* Possibly gets more people to pay attention to the question of
whether a document that is about to be published is really
consistent with the one about which the community reached
consensus (something I do not believe exposing the AUTH48
correspondence will accomplish nearly as well if at all).   And 
* Encouraging those who are already part of the AUTH48 process
-- authors, ADs, WG Chairs, shepherds, etc.(?) -- to take more
responsibility for saying "hey, this is departing too much from
the original document, let's pause and go back to the community"
in a timely way, both because it is The Right Thing and because
it would avoid the overhead and delays associated with appeals.

thanks for reading.
   john

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 26 Feb 2022 18:42:39 +0100

On 2022-02-26, at 17:53, John C Klensin <[email-masked]> wrote:
> 
> I have tried to review this very active discussion up to
> now.  

I’m starting to understand that this discussion is a great dress rehearsal for how RSWG will operate.

Maybe we can take the opportunity and kick off the experiment proposed by the IESG now and go into the greater discussions once RSWG is operational.

Grüße, Carsten

---

From: John C Klensin <[email-masked]>
Date: Sat, 26 Feb 2022 12:50:26 -0500

--On Saturday, February 26, 2022 18:42 +0100 Carsten Bormann
<[email-masked]> wrote:

> I'm starting to understand that this discussion is a great
> dress rehearsal for how RSWG will operate.
> 
> Maybe we can take the opportunity and kick off the experiment
> proposed by the IESG now and go into the greater discussions
> once RSWG is operational.

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.

Hmm.  That has been proposed before, so this suggestion probably
adds to the reasons for taking that path.  Probably the informal
guidance to the IESG right now should be that, with the new RFC
Editor Model being so close to completion, making _any_ changes
that could impact the RFC Editor Function should be deferred
until the new processes are in places unless they are needed to
deal with clear emergencies.

    john

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Sat, 26 Feb 2022 17:55:38 +0000

+1 to deferring changes that could impact the RFC Editor Function

	Tony

On 2/26/2022, 12:50 PM, "John C Klensin" <[email-masked]> wrote:

        john

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Feb 2022 09:19:23 +1300

> tell you whether the rest is worth reading.

It is, and I hope we can discuss the suggestion in para 2) c) in the RSWG.

    Brian

> .

---

From: Michael Richardson <[email-masked]>
Date: Sat, 26 Feb 2022 16:58:32 -0500

Perhaps we need a 1-minute (physics) video, in the spirit of "A Bill is Just
Bill on Capital Hill" to explain the RFC process.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 26 Feb 2022 17:07:20 -0500

Michael Richardson <[email-masked]> wrote:
    > Perhaps we need a 1-minute (physics) video, in the spirit of "A Bill is
    > Just Bill on Capital Hill" to explain the RFC process.

Uhm, I fat fingered the send now button.
     "I'm just a Bill"

The link to go long with this is:
   https://www.youtube.com/watch?v=OgVKvqTItto

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 26 Feb 2022 23:21:16 +0100

> both of which tend to create inertia for keeping “experiments”

Wow.

I’ll shut up now, but not before pointing out the absurdity.

The original proposal by the IESG, as agreed to by the other streams, was a simple stopgap measure to obtain additional transparency in the AUTH48 process by an absolutely minimal amount of procedural and technical change.  Create a mailing list, start adding that to the RFC editor AUTH48 mails.  Can be implemented (business sense) in an afternoon, can be stopped in an afternoon if it breaks in unexpected ways.

Beautiful engineering, and something that doesn’t need to be flogged to death (also because it already is agreed).

Those of us that have been using the AUTH48 process for a couple decades now know that we need to improve the process on at least two major fronts:

1 — giving the authors and the other process participants better tools, in particular a way to continue to work on AUTH48 with the same tooling that was used in the WG and IESG segments of the document development (git and GitHub, domain-specific automation, authoring tools).
2 — giving the WG a better stance in the process, without derailing the process by encouraging relitigating WG dissent during the completion of an approved document (and without creating further process steps that impede the improvements usually provided by the RFC editing process from approved document to RFC).

Yes, we should work on these work items in the new structure we are now creating.
These will be multi-year processes, not the least because it will be hard to achieve continuous improvement in a structure that favors turning everything into grand endeavors.
Which is a great reason to make a small continuous improvement step now.

And, by the way, the stopgap would actually be very useful in generating real-world data that can inform 2.

Grüße, Carsten

---

From: John C Klensin <[email-masked]>
Date: Sat, 26 Feb 2022 18:14:51 -0500

--On Saturday, February 26, 2022 17:07 -0500 Michael Richardson
<[email-masked]> wrote:

>     > Perhaps we need a 1-minute (physics) video, in the
> spirit of "A Bill is     > Just Bill on Capital Hill" to
> explain the RFC process.
> 

Would you propose doing that now, after the new Model has
settled in enough that one can describe the new process (noting,
in particular, that, in case of disputes, the RSE now has a role
(and authority) while, in the new model, the RSCE does not
unless the whole RSAB gets dragged in).   Or would you propose
to do it twice?

And, while a Bill is Just a Bill on Capital Hill, the different
streams, and, in practice, the different treatment of WG and
non-WG and Informational and Experimental versus Standards Track
documents in the IETF Stream would probably take a lot more than
a minute :-)

Another argument for deferring this until the RSWG can get into
the act?

   john

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 26 Feb 2022 15:30:30 -0800

> On Feb 26, 2022, at 3:14 PM, John C Klensin <[email-masked]> wrote:
> 

Congresspeople would have the same observation, e.g., riders, reconciliation, etc. all complicate the process.

The point appears to be “it should be able to be explained simply, in a 3 minute video”, and Einstein would agree.

Joe

---

From: Michael Richardson <[email-masked]>
Date: Sun, 27 Feb 2022 20:15:05 -0500

John C Klensin <[email-masked]> wrote:
    >> Michael Richardson <[email-masked]> wrote: > Perhaps we need a
    >> 1-minute (physics) video, in the spirit of "A Bill is > Just Bill on
    >> Capital Hill" to explain the RFC process.
    >>
    >> Uhm, I fat fingered the send now button.  "I'm just a Bill"
    >>

    > Would you propose doing that now, after the new Model has settled in
    > enough that one can describe the new process (noting, in particular,
    > that, in case of disputes, the RSE now has a role (and authority)
    > while, in the new model, the RSCE does not unless the whole RSAB gets
    > dragged in).  Or would you propose to do it twice?

I think that 97% of how an internet-draft becomes an RFC will not be changing
as a result of the RSCE.  If we started work on such a 3-minute video today,
it is unlikely we'd finish it prior to the new Model settling in.
I don't think that the details about disputes, etc. would even make into the video.
But, if the powers that would be paying for such a thing wanted to wait a few
months, that would be fine with me.

    > streams, and, in practice, the different treatment of WG and non-WG and
    > Informational and Experimental versus Standards Track documents in the
    > IETF Stream would probably take a lot more than a minute :-)

I did rewatched Just a Bill (and the 2014 SNL spoof of it, where Executive
Orders were explained...), and I don't think that it went into any details about
the different ways that bills go through committee, or the twelve different
ways in which the bill can be filabustered.  It's not important.

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 28 Feb 2022 01:45:40 +0000

> ways in which the bill can be filabustered.  It's not important.

Ok, I bit. Here's the lyrics, should just take a few minutes for a talented
vocalist to record.

I'm just a draft
==========

oof, you sure gotta complete a lot of steps to get something up on the
datatracker
I wonder what that sad little scrap of HTML is?

I'm just draft, yes an Internet-Draft, and I'm sitting here under Note Well.
Well it's a long long journey to the RFC series
It's a long long wait while I'm sitting as an I-D
But I know I'll be a RFC
At least I hope and pray that it's fast, but today I am still just a draft

Gee I-D, you certainly have a lot of patience and typos
Well I got this far.
When I started I wasn't even written, I was just an idea.
Some devs back home decided they wanted a spec,
so they called their local WG chair and they said
"You're right, this ought to be an RFC"
And they sat down and issued an adoption call
And I became an adopted I-D.
And I'll remain an I-D until they decide to make me an RFC.

I'm just draft, yes an Internet-Draft, and I got as far datatracker.
Well, now I'm stuck in consesus, and I'll sit here and wait.
While the WG members discuss and debate.
Whether they should let me be an RFC.
Well I hope and pray that it's fast, but today I am still just a draft.

Listen to that WG arguing. Is all that discussion and debate about you?
Yeah, I'm one of the lucky ones. Most drafts never even get this far.
I hope they decide to report on me favourably.
Otherwise I may die.
Die?
Yeah, die in consensus.
Ooh, but it looks like I'm going to live.
Now I go to the IETF Last Call and they critique me.
If the say yes, what happens?
Then I go to the IESG and the whole thing starts all over again.
Oh no!
Oh yes.

I'm just draft, yes an I-D, and if they ballot me in IESG.
Well then, I'm off to the RFC queue.
Where I'll wait in a line.
With a lot of other drafts, for the editor to refine.
And if they AUTH48 me then I'll be an RFC.
I hope and pray that it's fast, but today I am still just a draft

You mean even if the whole IETF says you should be an RFC, the editor can
still say no?
No that would be called a veto
If the RFC editor could veto, that would be a failure to separate concerns.
And by that time it would be too late to veto anyway.

It's not easy to become an RFC is it?
No!
But how I hope and pray that it's fast, but today I am still just a draft

They published you I-D, now you're an RFC.
Oh yeah!

Errata
=====

My introduction to this Just a Bill song was via the Simpsons "I'm an
amendment to be" [1], which reminded me a bit of errata, so here's also an
additional bonus:

Hey, who left all this garbage in the RFC?
I'm not garbage, I'm an erratum to be, yes an erratum to be.
And I'm hoping that they'll validate me.
There's a lot of editorials in the examples
And I want to make them correct because I treat them as normative and
nobody else does
but I hope and pray that they will,when it's fixed.

Can't we just fix the text directly?
No! Because that would mean that the RFCs are mutable.
But if we say they are immutable, we can store the erratum
and fix it by rewriting the RFC.

Good news erratum. They verified you. Now you'll sit in the errata page
that everyone forgets about.
Oh yeah!

Cheers
Lucas

[1] - https://youtu.be/w8gt-EEpelY?t=15

---

From: John C Klensin <[email-masked]>
Date: Sun, 27 Feb 2022 20:58:44 -0500

--On Friday, February 25, 2022 10:03 -0800 Larry Masinter
<[email-masked]> wrote:

> With the move to XML and renderings of a new RFC in different
> formats, who is responsible for reviewing the different
> renderings for unintended changes in meaning? If it's the
> authors, I'd hope that a change in AUTH48 might offer some way
> to spread the burden.
> 
> FWIW

Larry, based on the last document with which I went through
AUTH48 (in the first half of 2020), it wasn't clear who, if
anyone, was responsible for checking the different formats and
renderings.  Of course, the theory is that, if the XML is
correct, everything else should take care of itself.   I haven't
felt it would be useful to try to push on that before the new
model was in place although, back then, I hadn't dreamed it
would take this long.   But I agree with you that review should
be done and that we need to think about how to do it, ideally
without over-stretching or over-stressing the RPC.

   john

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Feb 2022 16:44:50 +1300

On 28-Feb-22 14:15, Michael Richardson wrote:

> as a result of the RSCE.

I'd say 100%. I'm no good at videos or poetry, but I can work LibreOffice.
An attempt at a diagram (two pages) is at https://www.cs.auckland.ac.nz/~brian/id-flow.pdf
As far as AUTH48 goes, it corresponds to current practice.

I'm more than happy to put the source file on github if anybody's interested.

     Brian

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 27 Feb 2022 20:52:45 -0800

I think you left out WGLC.

Joe

—

> On Feb 27, 2022, at 7:44 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Brian Carpenter <[email-masked]>
Date: Mon, 28 Feb 2022 19:03:01 +1300

There are quite a few things missing. The challenge is where to stop, and
how much detail do you want in tutorial diagram.

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Mon, 28 Feb 2022, 17:52 [email-masked], <[email-masked]>
wrote:

> An attempt at a diagram (two pages) is at
> https://www.cs.auckland.ac.nz/~brian/id-flow.pdf

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 28 Feb 2022 01:13:36 -0500

I would have thought that the primary thread that would be useful to be 
shown for a draft is:

Individual draft
discussion and improvement
WG adoption (no details, just that it usually occurs)
discussion and improvement
WG Last Call w/ discussion
AD Review w/ discussion
IETF Last Call w/ discussion
IESG Approval w/ discussion
editing
Publication

With some notation somewhere that advancement along that sequence is not 
guaranteed.

Yours,
Joel

On 2/28/2022 1:03 AM, Brian Carpenter wrote:
> There are quite a few things missing. The challenge is where to stop, 
> and how much detail do you want in tutorial diagram.
> 
> Regards,
>      Brian Carpenter
> On Mon, 28 Feb 2022, 17:52 [email-masked] 
> <mailto:[email-masked]>, <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     www.strayalpha.com <http://www.strayalpha.com>
> 
>>     On Feb 27, 2022, at 7:44 PM, Brian E Carpenter
>>     <[email-masked] <mailto:[email-masked]>>
>>     wrote:
>>
>>     <https://www.cs.auckland.ac.nz/~brian/id-flow.pdf>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Feb 2022 09:37:37 +0100

> renderings.  

“Responsible”: The authors of course (in theory).

> Of course, the theory is that, if the XML is
> correct, everything else should take care of itself.  

Well, that isn’t even a theory.
Xml2rfc has its mysterious ways.

More importantly, implementers will look at a rendering (TXT, HTML/PDF).
If that is confusing, you will have interoperability problems (or low take-up).
So authors will typically check one of the renderings in some detail.
(Only with a lot of luck, they will seriously both TXT and HTML or PDF, which unfortunately is really needed in particular since 3.10.0.)

Where aspects of the XML are not visible in the renderings, the RPC has started to ask specific questions.
E.g., for the type= attributes of <sourcecode elements.
I’m not sure there is a checklist of invisible aspects.
It would help to have an debug-the-XML rendering where all these invisible aspects become visible.

In summary, I think that a theory where authors are responsible for the XML will stay fiction.
The RPC is much better off doing this, being used to operate in that noisy environment, and (I hope) more aware what went wrong in previous RFCs.

Grüße, Carsten

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 28 Feb 2022 14:57:38 +0000

Not having looked at the diagram, I am curious what this offers that is “better” (for some definition, you pick) than RFC 2028-bis or the IETF Tao?

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 28 Feb 2022 08:18:26 -0800

Agreed, but I think WGLC as the gate to IESG review is an important step and the only one such step missing.
Joe

—

> On Feb 27, 2022, at 10:03 PM, Brian Carpenter <[email-masked]> wrote:
> 
> There are quite a few things missing. The challenge is where to stop, and how much detail do you want in tutorial diagram.
> 
> Regards,
>     Brian Carpenter
> On Mon, 28 Feb 2022, 17:52 [email-masked] <mailto:[email-masked]>, <[email-masked] <mailto:[email-masked]>> wrote:

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 28 Feb 2022 08:21:52 -0800

Hi, Joel,

> On Feb 27, 2022, at 10:13 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> I would have thought that the primary thread that would be useful to be shown for a draft is:
> 
> Individual draft

What’s the difference between AD review and the IESG step (isn’t that Review with discussion)?
I.e, why not:

Individual draft
discussion and improvement
WG adoption (no details, just that it usually occurs)
discussion and improvement
WG Last Call w/ discussion
// remove: // AD Review w/ discussion
IETF Last Call w/ discussion
IESG //Review, changed from: Approval // w/ discussion
editing
Publication

> With some notation somewhere that advancement along that sequence is not guaranteed.

As a flowchart, it’s not just that things can fail to advance, but at any point a doc can also be abandoned (i.e., exit the process).

But those steps are often easier to indicate as a note, rather than arcs everywhere.

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 28 Feb 2022 11:37:15 -0500

Joe, in all cases I know of when the WG chairs push the button to send a 
document to the IESG, what this causes is a review by the responsible 
AD.  In many cases, the AD has questions he would like answers to before 
he pushes the button causing the IETF LC.  Given that this is the 
typical case, I would expect to include it.

Yours,
Joel

On 2/28/2022 11:21 AM, [email-masked] wrote:
> Hi, Joel,
> 
>> On Feb 27, 2022, at 10:13 PM, Joel M. Halpern <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>     *// remove: //* AD Review w/ discussion
>     IESG *//Review, changed from: Approval // *w/ discussion
>     editing
>     Publication
> 
> 
> As a flowchart, it’s not just that things can fail to advance, but at 
> any point a doc can also be abandoned (i.e., exit the process).
>

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Mon, 28 Feb 2022 16:41:50 +0000

If you're serious about this list, then I would change all of the "w/ discussion" to "w/ discussion and improvement". :)

	Tony

On 2/28/2022, 11:37 AM, "rfc-interest on behalf of Joel M. Halpern" <[email-masked] on behalf of [email-masked]> wrote:

    Yours,
    Joel

    _______________________________________________
    rfc-interest mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.rfc-editor.org/mailman/listinfo/rfc-interest__;!!BhdT!g4_xZX0AYPTmxDjZKfVxZ0n0LwMi9Gv14ulsnyPxZwwf9XVAowEk6Xa9W1iSb-gmc-Ls_bYO$

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 28 Feb 2022 11:49:13 -0500

That level of wordsmithing I happily leave to whomever is tyring to turn 
this into something consumable.  (I considered even leaving out the w/ 
discussion) part, but thought that point was important enough to make. 
Still up to others if it stays.  or gets moved to a note.  Or...)

Yours,
Joel

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 28 Feb 2022 17:52:20 +0100

> If you're serious about this list, then I would change all of the "w/ discussion" to "w/ discussion and improvement". :)

Absolutely.

Is the subject line still relevant this discussion?

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Mar 2022 09:59:59 +1300

Sure, but getting all that in one diagram really requires a papyrus
scroll. I'll leave that to a more accomplished digital artist.

Regards
    Brian Carpenter

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 28 Feb 2022 15:31:10 -0800

Joel,

Thanks; I forgot about this step largely because most of my drafts have been either in the AD’s master WG or a WG the AD was chairing anyway.

However, I’m not sure it’s a formal step (I can’t seem to find it listed as such anywhere). AFAICT, it’s just a courtesy vs IETF LC or IESG review.

Joe
—

> On Feb 28, 2022, at 8:37 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> Joe, in all cases I know of when the WG chairs push the button to send a document to the IESG, what this causes is a review by the responsible AD.  In many cases, the AD has questions he would like answers to before he pushes the button causing the IETF LC.  Given that this is the typical case, I would expect to include it.
> 
> Yours,
> Joel
> 
>>> On Feb 27, 2022, at 10:13 PM, Joel M. Halpern <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Mar 2022 13:32:31 +1300

On 01-Mar-22 03:57, Salz, Rich wrote:
> Not having looked at the diagram, I am curious what this offers that is 
“better” (for some definition, you pick) than RFC 2028-bis or the IETF Tao?

I don't think either of those addresses the specific question of what are 
the stages in the path from a -00 individual draft to a published RFC.

And a diagram/flow chart with an attached text commentary would be useful 
material for newcomers. A video version might be a nice touch, but with a 
bit more content than "I'm just a bill".

Another topic for EMO to discuss, I think.

     Brian