Eric, As a long-time believer in the "if it ain't broke, don't fix it" principle, this is fine but please keep three things in mind. (i) While almost all ADs, shepherds, and authors act with integrity almost all of the time, in many cases each has incentives to "just get done" with documents, especially documents that have dragged out for one reason or another. As I think Keith has been trying to point out, the edge cases rarely represent bad behavior, only difference in judgment. (ii) As I said in my response to Brian, while I recognize the advantages of diffs, requiring a change log for changes initiated after a WG's publication request (or, at latest, after Last Call starts) would help document (or, at least, alert people to) substantive changes and the reasons for them, information that can now be scattered across the Last Call list, the WG list, Github repositories and pull requests, and private correspondence among various parties. (iii) Another part of my initial note was a suggestion that we get better at announcing decision points. Even if no additional review procedure or comment mechanism is needed --i.e., if the answer to the edge cases Keith and I are concerned about is the appeal mechanism-- early and clear announcements of decisions might get appeals in early enough to avoid significant delays (see the first "aside" below). thanks, john (Two side comments, for those who haven't stopped reading by now, two more general comments) Aside 1: As many people know, I've argued on and off for years that we misnamed the appeals process because it sounds very judicial when it was (at least IMO) intended as more of a "hey, please reconsider this using information you may not have had or considered" one. I've sometimes wished we had more appeals, enough of them to be considered routine checks on the process rather than as A Big Deal. However, looked at either way, the two month window for lodging an appeal can be a serious impediment to rapid progress. In particular, because RFCs cannot be changed once published, the new model that makes the editing and AUTH48 process public turns "finished and ready to publish" into a decision point. That, in turn, probably implies that documents should be frozen at that point for two months to see if an appeal arises before actual publication. I hope we never go down that path, but we are now open to an appeal that a document in the IETF Stream was improperly published because insufficient time was allowed for an appeal to be filed after AUTH48 concluded and that is inconsistent with both the intent of RFC2 2026 and fairness. Aside 2: As suggested above, authors (who are often very tired of quibbling over documents with with they thought they were finished), WG Chairs (whose WGs concluded that a document was finished before requesting publication), shepherds (whose designation/ title implies helping to move a document along), and even ADs (who may be overloaded with other things) have incentives to decide to treat issues as non-substantive and "just" get the documents out. To their credit and that of the system, that rarely happens as you (Eric) and Ben pointed out. However, if we really want to be confident that a small review team of that sort are the right people to fairly judge whether, e.g., an additional Last Call is needed or a document should be returned to the WG (at least for a quick "after these changes, do you still believe this should go forward" check), then the IESG should be appointing, not just a shepherd but a Devil's Advocate whose role should be to find and expose reasons why a particular document is not ready for publication or should not be published at all. I assume you would have trouble finding candidates for that difficult and thankless role and am not actually suggesting it, but the logic should, I hope, be clear. --On Sunday, 26 June, 2022 06:38 +0000 "Eric Vyncke (evyncke)" <evyncke@xxxxxxxxx> wrote: > The publication process has human beings (ADs but also authors > & shepherds) in the loop in order to provide a judgement call > on the changes at any stage (up to AUTH48). And, like Ben > wrote, the current IESG members tend to err on the cautious > side, i.e., request another Last Call by the community (and > explicit forward to the originating WG if applicable). > > On the diff side, personally, I prefer to rely on a diff tool > than on the authors' change log. > > So, John's concern is valid, but I think to process already > cares about it.
