On Fri, Dec 20, 2024 at 6:25 PM John C Klensin <john-i...@jck.com> wrote:
> > > --On Friday, December 20, 2024 18:41 -0600 Jean Mahoney > <jmaho...@amsl.com> wrote: > > >> I think the consensus is a version of the process in which we > >> *never* issue a patch for new readers. That is, we rename errata > >> as "issues", and there is never a "verified" state. > > > > [JM] What I meant by patch was like the inline errata -- a reader > > can see the original text and the corrected text. > > Yes, Jean, but that takes us full circle, back to what several of us > have objected to in different ways. Except for cases that are > trivial and/or obvious -- ones for which a corrected version might be > pleasing or desirable but is really not needed -- having inline > errata raises several issues including: > > (1) For RFCs with "corrections", there are suddenly two versions -- > the original and the "corrected" one-- that might differ > substantively. > (2) If there is more than one correction over time, it places a > burden on readers to be sure they are looking at (and, for > implementers or conformance evaluators, relying on) the most recent > version, even if they are looking at a version that was downloaded > only days earlier. Of course, if we could prevent people from ever > downloading RFCs or quoting from them and could view every > implementation as a moving target that would not be a problem but, at > least IMO, those are not realistic constraints. > (3) No verification model we are likely to be able to come up with > will carry the same level of authority about community consensus as, > e.g., an IETF LC. And IETF Last Calls are far too heavyweight for > almost all "corrections".** > I agree that there is the potential for confusion in these cases, but that needs to be balanced against the reality of confusion when the document is simply wrong and there is practical way to correct it short of issuing a -bis, which, as you note, is very heavyweight, and, even in the best case, means that the wrong document is the only one for quite some time during the development of the -bis. > ** I did not respond to a comment made earlier that pointed out that > changes made during editing or AUTH48 don't get community review and > hence sometimes don't represent community consensus either. But the > advantage _that_ process has is that issues and discussions > associated with a document that presumably was approved only a short > time ago are likely to still be fresh in people's minds and authors > and ADs are able to go back to WGs or others active in discussions to > check things (and many do). I agree that this is true, but I don't think it's particularly relevant. There are two distinct questions here: 1. Whether a given change needs community consensus. 2. Whether a given change is advisable. It's true that having the document be old makes (2) difficult, but I don't think it's unreasonable to believe that the AD is still able to evaluate (1). > IMO, if a document changes in > significant ways during editing or AUTH48 without consultation with > the community, that is a system failure and should not be used to > justify other system failures or abuse of claims of community > consensus. > I'm not sure what you mean by "significant", so I'm unable to determine whether the changes you are referring to are system failures. In my experience documents often change quite a bit during copy editing, including changes initiated by the RPC (indeed, it's something we are paying the RPC to do). I would consider those changes significant--indeed in some cases as an author I object to them, but I don't think they need the approval of the WG or the community. I would instead use the term "semantically meaningful", to distinguish changes which need community approval. I agree with you that a system failure in one part of the process does not justify other systems failures, but as I don't consider either of these to be a system failure, it's not what I am suggesting. -Ekr
-- rswg mailing list -- rswg@rfc-editor.org To unsubscribe send an email to rswg-le...@rfc-editor.org
