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
