On 6/25/19 12:15 PM, Christian Huitema wrote:
We inherited a structure in which RFC are immutable. This leads to the errata process and long cycles of updates by WG processes. Is that the best we can do?
I have many times observed the value in RFCs being immutable - e.g. as prior art in patent cases (which actually improves the ability of the public to use our protocol standards) and to minimize confusion between versions (if you're quoting RFC XXXX for some particular XXXX it means the same thing to everybody, rather than having to also cite a date or version).
I believe having RFCs be immutable also discourages churn and makes our product more stable by discouraging participants from fighting the same battles forever.
(It doesn't prevent that entirely of course, and I've been distressed more than once to see a working group task with revising an old RFC used as an opportunity to invalidate good work done years earlier, not for sound technical reasons but simply because some people didn't like it or it didn't suit their politics.)
Mostly I think having RFCs be immutable is the right choice. That's not to say that there's no room for improvement at all. I could see a model where the specifications are living documents and the RFCs are snapshots of those documents at particular points in time that have been subject to thorough community review. But it would take a lot of rethinking of our process to make that work well, and we could easily end up with a result that's far worse than what we have.
If I were making an ordered list of which IETF problems need the most attention, this would be very far down on the list. I'm much more concerned, for instance, with the growing tendency of "IETF" (in the broad sense) to fragment into separate organizations that each see different self-interests, and the consequent danger of friction between these organizations to work at cross-purposes with IETF's broader mission.
Keith
