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" <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
