The main issue I have with this as written is that the process it describes for making the exception can still take too long. The *best* we can do in the described process is a little more than four weeks: publish a draft and immediately last-call it, allow the last call to run for 4 weeks, then have an emergency IESG meeting to approve it. If everyone's on top of everything, that can get approval in less than 5 weeks. For *this* case, that would be enough if we did not ALSO have to get this BCP approved. There could be situations that are more urgent than that. What if we should encounter a situation that needed a decision in three weeks? I would be happier, if we're going in this direction, to include an escape for real time-sensitive emergencies that allows the IESG to make a decision as necessary, with appropriate accountability to the community for it. Barry On Fri, Mar 27, 2020 at 4:03 PM Pete Resnick <resnick@xxxxxxxxxxxx> 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." > > pr > -- > Pete Resnick https://www.episteme.net/ > All connections to the world are tenuous at best > > Forwarded message: > > > From: internet-drafts@xxxxxxxx > > To: Pete Resnick <resnick@xxxxxxxxxxxx>, Peter W. Resnick > > <resnick@xxxxxxxxxxxx> > > Subject: New Version Notification for draft-resnick-variance-00.txt > > Date: Fri, 27 Mar 2020 13:00:54 -0700 > > > > A new version of I-D, draft-resnick-variance-00.txt > > has been successfully submitted by Peter W. Resnick and posted to the > > IETF repository. > > > > Name: draft-resnick-variance > > Revision: 00 > > Title: Variances to Provisions of Best Current Practices > > Document date: 2020-03-27 > > Group: Individual Submission > > Pages: 3 > > URL: > > https://www.ietf.org/internet-drafts/draft-resnick-variance-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-resnick-variance/ > > Htmlized: https://tools.ietf.org/html/draft-resnick-variance-00 > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-resnick-variance > > > > > > Abstract: > > From time to time, there are unforeseen circumstances which make > > following the requirements of a Best Current Practice (BCP) > > untenable, or where the procedures described in the BCP gives no > > guidance. This document defines a process for the IETF to grant a > > variance to any IETF process for a single use or of very short > > duration. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat >
