--On Friday, February 25, 2022 16:37 +0000 "HANSEN, TONY L"
<tony@xxxxxxx> 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
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.
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
_______________________________________________
rfc-interest mailing list
rfc-interest@xxxxxxxxxxxxxx
https://www.rfc-editor.org/mailman/listinfo/rfc-interest
.
