On Sat, Aug 20, 2022 at 1:29 PM, Paul Hoffman <paul.hoff...@icann.org> wrote:
> On Aug 20, 2022, at 10:07 AM, Warren Kumari <war...@kumari.net> wrote: > > Pausing publication is an unusual, but definitely not unprecedented, step. > Although we are able to make changes until a document is published as an > RFC, once it is approved and sent to the RFC Editor, we should only make > (non-editorial) changes in exceptional circumstances… > > Isn't this *exactly* what update documents are for? The protocol in > draft-ietf-dnsop-svcb-https is already a standard; it simply hasn't been > published as an RFC yet. It is also already widely implemented and > deployed. > > If there is a problem with the protocol specification, particularly one > that is re-litigation of earlier arguments, anyone can offer a new draft > that updates the protocol. In this particular case, AliasMode was heavily > discussed in the WG and the document was revised based on those discussions > before the protocol was standardized. > > It would be good to understand why this particular case of feature > re-litigation is enough to cause a message such as this. > Yes, yes it would be — however, see: "... and I wasn't really able to parse his issue with the document, so I ask him to clearly state the issue on-list when he returns." See also: "As the document was already extensively discussed and approved, we should only make substantive changes if they are very clearly warranted (e.g something that would otherwise be an errata, or "OMG! That clearly doesn't work, 1+1 doesn't equal 17…") — this is *not* an opportunity to re-litigate existing decisions, make non-required changes, etc." As for why this case: 1: Brian's email used phrases like "this is a catastrophic bug" and "it cannot be used (because of web browser client ambiguities and different interpretations by different implementers already)." I cannot tell if his concerns are valid (and am waiting for him to come back and clearly state them), but erring on the side of caution seems the right thing to do. 2: "The IESG is expected to ensure that the documents are of a sufficient quality for release as RFCs, that they describe their subject matter well, and that there are no outstanding engineering issues that should be addressed before publication." - https://www.ietf.org/standards/process/role-iesg-standards-process/ . I believe that if a participant raises a clear warning (see #1) that there are significant issues with a document, and if we *can* address them before publication, we really should. Publishing RFC9xxxx and then having to publish RFC9xxy saying "Oh, no, we made a mistakes, replace Section X with Section Y" is inefficient, causes confusion, and undermines the RFC system. If indeed Brian's concerns are valid and we find that the RFC is "wrong," publishing it as is not the right thing to do. 3: The document was stuck anyway - it is in MISREF waiting for another document which has't been received yet. 4: One of the authors on the document is employed by Google, and Brian said that he believes that Google Chrome's interpretation of the document is incorrect. In addition to being OpsAD, I am also employed by Google, and so I believe that I need to err on the side of caution and transparency to ensure that there is no conflict or perception of conflict. This was very much a secondary consideration though. Reasons 1 and 2 are more than enough for me to say "Let's pause this while we make sure that we are not publishing something with an error, especially in light of the fact that it doesn't actually delay the RFC..." W > --Paul Hoffman > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
