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
On Fri, Feb 25, 2022 at 12:51 AM Ted Hardie <ted.ietf@xxxxxxxxx> 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. 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.
On Thu, Feb 24, 2022 at 10:25 PM The IESG <iesg@xxxxxxxx> wrote:
>
> 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 iesg@xxxxxxxx or reply to this
> thread by 24 March 2022.
>
> Francesca Palombini for the IESG
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
rfc-interest mailing list
rfc-interest@xxxxxxxxxxxxxx
https://www.rfc-editor.org/mailman/listinfo/rfc-interest
