On Mon, Dec 16, 2024 at 12:41 PM John C Klensin <john-i...@jck.com> wrote:
> > The third should probably be sent to a relevant WG mailing list (even > for closed WGs) for review. Opinions of the authors should be sought > to inform that discussion. But, as long as we are going to publish > errata in a form that implies that verified ones actually change the > underlying RFCs (e.g., by making an "errata included" form of the RFC > available), then the same criteria for initial publication of the RFC > should apply, i.e., approval from participants in an appropriate > subject-matter mailings list (typically a WG one), IETF Last Call, > and signoff from the IESG. > I certainly do agree that there are some concerns about errata being used to make substantive non-consensus changes to the text, but I don't agree that that means that every non-trivial erratum needs to go through IETF Last Call, the IESG, etc. I would make two points: 1. As noted in draft-farrell, because errata are not part of the "immutable" RFC text, if one is incorrectly approved, we can just unapprove it and not render it going forward. 2. As I've noted in draft-rescorla-rfc-jit [0], we actually routinely make nontrivial changes in the text that goes into the RFC in Auth48, with the AD being trusted to know what requires a new IETF LC, etc. I don't see why they can't be trusted here, when the stakes are lower, as noted above. -Ekr [0] https://www.ietf.org/archive/id/draft-rescorla-rfc-jit-00.html#name-ietf-consensus
-- rswg mailing list -- rswg@rfc-editor.org To unsubscribe send an email to rswg-le...@rfc-editor.org
