On 3/27/20 6:37 PM, Pete Resnick wrote:
On 27 Mar 2020, at 17:22, Keith Moore wrote:
I think it's perfectly reasonable to publish a BCP for a one-time
variance. On the other hand I think it's a Very Bad Idea to invent a
lightweight variance procedure that allows for process exceptions
that aren't documented in the normal means, and which fragment the
historical record. Though I don't doubt anyone's intentions here, a
lightweight variance procedure will sooner or later inevitably be
misused. Also, it's never a great idea to hurriedly invent new
process when doing so can be avoided.
If you read my draft, you'll notice that for all intents and purposes,
all of the procedures of publishing a BCP are required anyway: It
requires a written draft, a minimum 4-week last call, and a conclusion
of consensus by the IESG. The only thing that is different is that it
doesn't require publication as an RFC, addition to the BCP series, or
an additional RFC or moving it to Historic when it no longer applies
(because, as the draft says, it can't last longer than a year without
actually publishing a BCP). So I don't see what the misuse vector
you're seeing is.
The problem I have is with not publishing as an RFC. I don't think
people should have to dig through email archives (which are not as
reliably archived as the RFC series) to find out what the whole IETF
process is, or even the evolution history of the IETF process. I think
even brief deviations from the process should be archived the same as
any other changes to the process.
But I'll flip this on its head: why did we suddenly become so concerned
about the overhead of publishing a single RFC, when as far as I can tell
we've had a pretty low bar for RFC publication all along?
Keith
