--On Saturday, November 2, 2024 10:48 +0000 Paul Wouters <paul@xxxxxxxxx> wrote: > On Nov 2, 2024, at 00:37, Dave Crocker <dhc@xxxxxxxxxxxx> wrote: > > [speaking with my AD hat on] >> Playing with spec text just because, gosh, we could do better, >> should be questionable for a spec and especially for the >> late-stage of a -bis effort >> > > I feel I need to remind you that the purpose of the IETF LC is > partially to allow people not closely following a WG mailing list > to become aware of an imminent publication of a draft. It is > expected to reach people who have not read this document before and > give them a chance to give feedback. > > It is not valid to discard these people's views as "too late in > the process". > > A dissent like this would also be expected to be mentioned in the > Shepherds Write Up, and if the responsible AD would continue to > bring this unmodified to the IESG, would at least be expected to > justify why textual changes were deemed not needed. Such > justification can definitely be accepted by the IESG, but not > because it's "too late in the process". Paul, Let me make two additions to the comments Dave and Pete have made on this subject and my comments a few minutes ago. I want to stress before I go further that I am commenting on the general collection of Last Call comments and not any particular comment or suggestion, particularly the TURN one. First, some of the frustration you are hearing, and why terms like "late" keep showing up, are not "well this should have been brought up before Last Call" but closer to "this should have been brought up _during_ last call". The Last Call was announced to end October 9. No critical comments, indeed no comments at all, were received before that window supposedly closed. The WG certainly had a reasonable right to expect that issues, if any, would have been raised during that window, giving a reasonable opportunity to have the document wrapped up so that everyone could plunge into the Applicability Statement during IETF 121 rather than having heated debates about rfc5321bis now. Given the scarcity of reviews, especially Area/Directorate reviews, I personally believe that Murray did the right thing by asking for reviews again as the Last Call period wound down and, again, personally, I believe that Last Call or not, IESG review or not, AUTH48 or not, if an issue that is significant, substantive, and technical is identified about a document up to the day the RPC announces publication, we should figure out how to consider it. Building a bit on Pete's remarks, another aspect of "too late" is that having comments that amount to "the WG was improperly chartered" (whether that was the intent of the comments or not) is problematic when they occur more than four years after that charter was approved. The charter text that Pete cited was the result of very careful consideration of traditional restrictions on changes to documents planned to be issued at Internet Standard level, issues with style of a document that has been explicitly a paste-together job since planning for what became RFC 2821 was first underway (a problem explicitly discussed in Section 1.2 of the current draft), and the observation that the SMTP extension model (dating from around 1992) was explicitly a way to add mechanisms to be used with SMTP, not for those new mechanisms to be _part_ of SMTP. Dave, Pete, and others have pointed out the latter in various ways. If that 30-year-old design decision (about software that is very widely deployed and that we are using to send these messages) was wrong, or the 1995 charter for DRUMS was incorrect, I hope you will agree that it is a little late to retroactively revisit and revise them. Second, I agree with your description of IETF LC. Personally, I have, over the years, raised many topics during Last Call that addressed substantive issues that had not been considered by the responsible WG and even, in a few cases, the the WG explicitly declined to consider. In several cases, I've been criticized for not participating actively in the WG if I cared about those issues and resented for raising the points during Last Call. I know how it feels from both sides and it one thing that has caused me, as document editor, WG chair, or AD at various times, to be extra-careful about dismissing Last Call comments. At the same time, for IETF LC comments, where many ADs (and IESGs more generally) have had the expectation that WGs carefully track and consider every comment, I think there has been, and should be, an expectation that comments address issues that have substantive impact on the specification. That does not mean editorial comments should not be welcome -- as an author or editor of a fair number of RFCs, I've welcomed suggestions from the community about how text could be made better right up to and during AUTH48 and have had more offlist conversations with individual community members about why a change, or some variation on it, is or is not actually an improvement than I can recount. But stylistic quibbling disguised as IETF LC comments to which WG responses are expected comes fairly close to disruptive. That is especially difficult with this particular document because, for the reasons noted above and in Sections 1.2 and 1.3, different portions of it reflect my style, Jon Postel's style, Craig Partridge's style, Bob Braden's style, and, in smaller portions, the styles of several others. That makes it really easy for readers to find material for which their stylistic preferences differ from choices made in the document -- and choices as to which suggestions to accept (whether made by the editor or the RPC) far more subjective and arbitrary than anything for which community consensus can be expected. For the record, I think the IETF LC process, especially Donald Eastlake's review, has caught a few substantive problems that the WG, because of the way it organized its work, did not spot. Those have either been fixed in the working draft or, where they are complicated, called to the WG's attention for discussion. Not only do I have no problem with that, I'm delighted. The complaint is only about relitigating old charter decisions, haggling about the editorial style, and similar things. As far as TURN itself is concerned, I have no problems with Mike's input: it seems to me that he asked a reasonable question. At the same time, the subsequent discussion, in combination with the knowledge that there have been no demonstrated problems with the current text since 2001, has convinced me that we should leave things alone in this document and, if people care about it enough to do the work, they/we should organize an effort that discusses the issues (including the security ones), the relationship to SMTP AUTH and SASL, the relationship to ETURN and other options, and make some recommendations. A document resulting from those recommendations should be at the Proposed Standard level because few of the ideas have been tested extensively in the environments in which they are likely to be most useful. Since you have put your AD hat on, I think some of this comes down to a question of what sort of IETF LC you would like. Deliberately oversimplifying, is it one that focuses on catching and addressing substantive technical issues that a WG overlooked, swept under the table, or got wrong? Also one that concludes in a timely fashion? Or do you prefer one in which we spend time second-guessing charter or document strategy decisions made years (sometimes decades) ago, quibbling about editorial issues on which the RPC should usually be the final authority, and having a process with a good chance of stretching out forever or until those who have done the work give up and walk away from the IETF? I know it is not that straightforward, but the question may be worth asking. Finally, the solution to the need for a good explanation of the interrelationships among out many email documents, both the core ones and the various extensions and attempts to work around issues with SMTP and relationships to other mail systems that the discussion of gatewaying in rfc5321bis do not cover, isn't trying to squeeze that into the SMTP spec. I doubt it is trying to stuff it into the applicability statement either although I think the WG should spend a bit of time on that question at its approaching meeting. Instead, I think the community should have a comprehensive document that lists email-related specs and discusses relationships (including non-obvious security issues as they emerge), possibly in the form of a web page or wiki rather than an RFC. And, no, I'm not volunteering to do the work, especially by myself. john -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
