Re: Things that used to be clear (was Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

[Benjamin Kaduk <[e-mail]>]

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
> 
>