On 25/02/2022 16:58, Eric Rescorla wrote:
On Fri, Feb 25, 2022 at 7:43 AM Francesca Palombini <
francesca.palombini@xxxxxxxxxxxx> wrote:
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.
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.
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
-Ekr
Thanks,
Francesca
*From: *iesg <iesg-bounces@xxxxxxxx> on behalf of Ted Hardie <
ted.ietf@xxxxxxxxx>
*Date: *Friday, 25 February 2022 at 16:15
*To: *Eric Rescorla <ekr@xxxxxxxx>
*Cc: *Working Group Chairs <wgchairs@xxxxxxxx>, admin-discuss@xxxxxxxx <
admin-discuss@xxxxxxxx>, IETF <ietf@xxxxxxxx>, RFC Interest <
rfc-interest@xxxxxxxxxxxxxx>, IESG <iesg@xxxxxxxx>, irtf-announce@xxxxxxxx
<irtf-announce@xxxxxxxx>, IETF Announcement List <ietf-announce@xxxxxxxx>
*Subject: *Re: [rfc-i] Public archival of AUTH48 communications
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
_______________________________________________
rfc-interest mailing list
rfc-interest@xxxxxxxxxxxxxx
https://www.rfc-editor.org/mailman/listinfo/rfc-interest
