Re: New Version Notification for draft-resnick-variance-00.txt

[John C Klensin <[e-mail]>]

--On Friday, March 27, 2020 16:55 -0500 Pete Resnick
<[e-mail]> wrote:

> On 27 Mar 2020, at 16:43, Spencer Dawkins at IETF wrote:
> 
>> <https://tools.ietf.org/html/rfc3933> would be almost
>> perfect for  this except that it takes too long for an
>> existential emergency (which  I believe seating a Nomcom that
>> the community [agreed] should be  seated would qualify).
>> Perhaps it's worth explaining why that BCP  isn't appropriate
>> in this case. 
> 
> Good point. 3933 also requires the publication of an RFC, in
> its case Experimental. For a one-time or short-lived variance,
> an RFC seems too heavyweight. I'll definitely add a reference
> and explain in -01.

As an aside, which we definitely should not take on now but I
hope doesn't get lost:  At the time 2026 and IIR even 3933 were
written, there was a reasonable expectation that the lag time
between IETF approval for publication of what we now call an
IETF-stream RFC and RFC publication would be rather short.   In
the subsequent decade and a half, we've seen a number of periods
in which that time has stretched out.  It is probably time to
update those two documents (and perhaps at least some others
that are tied to RFC publication) so that clocks start running
with the date of an IESG Protocol Action or Document Action that
signs off on the document (probably plus the window for appeal
of those actions and some rules about appeals in progress)
rather than the RFC publication announcement date.  Because of
the appeal problem, it would obviously require a more
complicated rule than "RFC publication", but I think multiple
events are suggesting that RFC publication may have become the
wrong benchmark wrt timing conditions on other events.
 
>...
>> Spencer, who would be fine if the community just said "Do The
>> Right  Thing. no process change required", but who would
>> feel better if we  knew the community had said that ... 
> 
> I've already seen a couple of comments that amounted to (at
> least) cringes to that suggestion, given that every proposal
> I've seen for NomCom 2020-2021 is going to be a rule change of
> some sort to 8713, so I'm not too sanguine about "no process
> change required".

+1 to cringe.  If nothing else, and noting the concern expressed
by Keith, Scott, Joel, and others, you could modify this
document to make the variance effective on the date of IESG
approval (whether that is generalized or not) and then let an
RFC be published to keep the record clear without affecting
either the start time or the end time of the variance.  Until
and unless the IETF and the broader community reach consensus
that an archival RFC series that provides a clear historical
trace, even of temporary process change decisions, is a 20th
Century concept that we should now move beyond, we should, IMO,
be very careful about "posting in a web page is good enough"
decisions. 

As far as web pages being archival, presumably just because we
expect institutions to be permanent and/or there are lots of
copies around... well that is another discussion entirely, but,
as I admire boxes of punch cards and other collections of
historical data that are in perfectly good physical condition,
"cringe" to that too (and, yes, I know the issues with the
physical media are different, but, again, another discussion).

(I have other reasons for cringing too, but won't repeat them
here.)

best,
   john