On Fri, Feb 25, 2022 at 2:19 PM Eric Rescorla <ekr@xxxxxxxx> 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. > > I don't object to a separate list that WG members could subscribe to. > > -Ekr > 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 > > 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
