On 3/27/20 4:02 PM, Pete Resnick wrote:
When I posted my suggestion for the short-term fix for the 2020-2021 NomCom, I mentioned that we would have to publish it as a BCP. Offline, Barry asked me why I thought publishing a new BCP was necessary for this one-off exception. But we don't have a mechanism in the IETF to directly violate a requirement of a BCP without writing another BCP. (Even the variance procedure for the standards-track document process defined in 2026 section 9 requires a published BCP.) He suggested that maybe we should have a process to do so. So I wrote a 3-page (well, 2-page plus boilerplate) BCP for a variance procedure for one-off or short-lived circumstances. I stole most of the text from 2026 section 9. If folks think this is sane, this will give us a simple procedure for saying, "Crazy thing happened that doesn't need to be documented beyond the mailing list and the IETF web site."
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.
Keith
