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

[Keith Moore <[e-mail]>]

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