On Mon, Jul 08, 2019 at 05:22:34PM -0400, Keith Moore wrote: > On 7/8/19 5:06 PM, Eric Rescorla wrote: > > > From my perspective, what is lacking is the ability to make minor updates > > to the RFC to correct grammar errors, fix obvious errors, clarify > > ambiguities, > > etc. without re-spinning the RFC. Something like TLS quickly accumulates > > a bunch of trivial errata of this kind that it's not worth re-spinning > > the RFC > > for, but would be useful to update the for readers. But as I said, that's > > a different problem. > > I guess I could see having a page to an annotated version of an RFC with > change bars, strikethroughs, etc. to indicate fixes to identified > errata. In other words, more or less the existing errata mechanism but > with a better presentation. But I'd want that page to show the Note that there's funding and, IIRC, a statement of work/RFP out for something roughly like this -- an annotated version of RFCs with (verified?) errata applied on top in a prominent way. https://www.ietf.org/media/documents/RFC_Errata_Merge_Tool_RFP_04-08-19_Appended.pdf -Ben > provenance of each change (submitted date, submitted by, approval date, > approved by, review comments) as footnotes or side-notes or whatever. > My concern is that if it becomes too easy to update an RFC, this > mechanism might be used to cause substantive changes that bypass the > IETF Consensus process. This seems especially likely to happen for > specifications that endure for decades and people who lack memory of why > certain decisions were made in the first place, exhibit action bias > toward making changes. > > I'd also be okay with having RFCs be updated this way in perpetuity, but > only if nontrivial updates required the IETF Consensus process (or > something like it) to approve the updates. I actually think that would > probably be better in many cases than re-spinning the RFC. Anytime an > RFC is re-spun there's a temptation to rewrite old language, which can > create unintended incompatibilities. If changes are approved as just > deltas, maybe this temptation could be minimized. > > There would still be a need to unambiguously refer to a particular > revision of an RFC. > > Keith > >
