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

From: "Pete Resnick" <[email-masked]>
Date: Fri, 27 Mar 2020 15:02:47 -0500

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: [email-masked]
> To: Pete Resnick <[email-masked]>, Peter W. Resnick 
> <[email-masked]>
> 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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 27 Mar 2020 16:43:39 -0500

Hi, Pete,

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 should be seated would qualify).
Perhaps it's worth explaining why that BCP isn't appropriate in this case.

Other than that, I'd only suggest using a numbered list in Section 2 so
people can follow the steps more clearly.

And thanks for taking this on.

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 ...

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 27 Mar 2020 16:45:17 -0500

Sorry, too many windows open at the same time.

On Fri, Mar 27, 2020 at 4:43 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> Hi, Pete,
>
> 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.
>

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 27 Mar 2020 16:55:53 -0500

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.

> Other than that, I'd only suggest using a numbered list in Section 2 
> so people can follow the steps more clearly.

I'll give it a go. It will take quite a bit of re-arranging of text. I 
was being lazy and copy/pasting from 2026. I'll see what I can do. Maybe 
wait for -02.

> And thanks for taking this on.

So far, it's been pretty easy. I'll reserve judgement before saying 
"you're welcome".

> 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".

pr

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Mar 2020 18:22:17 -0400

On 3/27/20 4:02 PM, Pete Resnick wrote:

> 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

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 27 Mar 2020 17:37:55 -0500

On 27 Mar 2020, at 17:22, Keith Moore wrote:

> 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.

pr

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Mar 2020 18:42:06 -0400

On 3/27/20 6:37 PM, Pete Resnick wrote:

>> 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 
> 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 
> 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

---

From: "Scott O. Bradner" <[email-masked]>
Date: Fri, 27 Mar 2020 18:46:30 -0400

+1

I have always felt that documenting a process (e..g moving to historic or invoking a variance) should be documented in 
our normal documentation series

Scott

> On Mar 27, 2020, at 6:42 PM, Keith Moore <[email-masked]> 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
> 
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Mar 2020 17:50:09 -0500

> NomCom, I mentioned that we would have to publish it as a BCP.

I'm not sure that's 100% correct. See, e.g., 
https://www.ietf.org/about/groups/iesg/statements/nomcom-eligibility-day-passes/

/a

---

From: Barry Leiba <[email-masked]>
Date: Fri, 27 Mar 2020 18:52:47 -0400

> any other changes to the process.

There's not a lot of "digging through" when we're posting it to
ietf-announce (fairly low-volume, and where things such as NomCom
announcements and other appointments, RFP decisions, and other Very
Important IETF-related decisions are posted).  I think, personally,
that the kinds of exceptions we're talking about here are pretty much
equally important to, say, the announcement of the NomCom chair, the
NomCom's decisions about whom to appoint to the IESG and IAB and LLC
Board, the IAB's appointment of ISOC BoT directors, and the like.  The
ietf-announce list is, in fact, where we archive all of that stuff.
None of it goes into RFCs.

> we've had a pretty low bar for RFC publication all along?

Because (1) there is significant overhead, and publishing them does
get in the way of publishing other RFCs (including clearing out
Cluster 238), and (2) the RFCs are an archival document series, which
we would LIKE to keep to things of actual, long-term importance.
Historical information is (and should be) available elsewhere.

Barry

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 27 Mar 2020 18:56:41 -0400

Arguably, this decision, and our reasoning around it, is important for 
archival purposes.

Yours,
Joel

---

From: "Scott O. Bradner" <[email-masked]>
Date: Fri, 27 Mar 2020 18:58:11 -0400

we agree to disagree

Scott

> On Mar 27, 2020, at 6:52 PM, Barry Leiba <[email-masked]> wrote:
>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 27 Mar 2020 18:58:45 -0400

Archival, yes, but not in the RFC series.

b

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Mar 2020 19:10:11 -0400

> https://www.ietf.org/about/groups/iesg/statements/nomcom-eligibility-day-passes/

I am not sure that it's within the IESG's purview to make such policy 
statements, especially since nomcom is not an IESG function.

Keith

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 27 Mar 2020 18:15:45 -0500

>> https://www.ietf.org/about/groups/iesg/statements/nomcom-eligibility-day-passes/

For your reading pleasure, here is the Last Call discussion on that 
statement, so there is precedent:

https://mailarchive.ietf.org/arch/search/?qdr=a&email_list=ietf&q=subject%3A(Policy%20Statement%20on%20the%20Day%20Pass%20Experiment)&as=1&so=date

> statements, especially since nomcom is not an IESG function.

The IESG is the consensus caller for BCPs, and the NomCom process is a 
BCP process, so I can see the argument. Also, the IESG was defining 
attendance at an IETF meeting, which could arguably be a reasonable 
thing for the IESG to do. YMMV.

pr

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Mar 2020 19:20:17 -0400

> https://mailarchive.ietf.org/arch/search/?qdr=a&email_list=ietf&q=subject%3A(Policy%20Statement%20on%20the%20Day%20Pass%20Experiment)&as=1&so=date 

Sure, but there's not a written consensus-approved process to approve an 
IESG statement that's not reflected in an RFC.   And IESG doesn't get to 
dictate how nomcom operates.

> thing for the IESG to do.

For other purposes, say whether someone gets a t-shirt, perhaps.   Not 
for nomcom purposes, IMO.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Mar 2020 13:52:11 +1300

> https://www.ietf.org/about/groups/iesg/statements/nomcom-eligibility-day-passes/

Yes. For the present emergency situation, I think that an IETF statement *notified to the ISOC Board* is necessary and sufficient. Notifying the ISOC Board is essential simply because they are the end of the appeals chain.

Pete's draft is not objectionable to me but I don't think it's necessary.

    Brian

---

From: Barry Leiba <[email-masked]>
Date: Sat, 28 Mar 2020 10:20:08 -0400

(Not picking Keith's comment, in particular: it was just convenient to
use for the reply here.)

For those of you who think the IESG should not (or is not allowed to)
exercise judgment here and make a one-time exception for this
exceptional situation:

Please advise how you think we can get the NomCom eligibility question
sorted out IN TIME to seat a 2020-21 NomCom, when we normally need to
ask for volunteers within the next 6 weeks.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Sat, 28 Mar 2020 10:28:15 -0400

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

---

From: Keith Moore <[email-masked]>
Date: Sat, 28 Mar 2020 12:21:55 -0400

I see your point but think that the action should be published in an RFC 
regardless of how it's made and I think the means of taking the decision 
need to respect RFC 2026 as much as possible given the constraints.   
However, I don't think it's necessary to wait for publication of the RFC 
before seating the nomcom.

Keith

---

From: John C Klensin <[email-masked]>
Date: Sat, 28 Mar 2020 15:22:00 -0400

--On Friday, March 27, 2020 16:55 -0500 Pete Resnick
<[email-masked]> 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).
> 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

---

From: S Moonesamy <[email-masked]>
Date: Sat, 28 Mar 2020 12:55:01 -0700

>(Not picking Keith's comment, in particular: it was just convenient to

In my opinion, Keith is correct.

>exercise judgment here and make a one-time exception for this

What is the meaning of "exercise judgement"? Is it something along 
the lines of an IESG Statement?

>ask for volunteers within the next 6 weeks.

Why is the above a problem for 2020/21?

The NomCom Chair is responsible for running the part of the process 
in which volunteers are selected.

Regards,
S. Moonesamy

---

From: John C Klensin <[email-masked]>
Date: Sat, 28 Mar 2020 16:15:31 -0400

--On Saturday, March 28, 2020 10:20 -0400 Barry Leiba
<[email-masked]> wrote:

> (Not picking Keith's comment, in particular: it was just
> convenient to use for the reply here.)
> 
> For those of you who think the IESG should not (or is not
> allowed to) exercise judgment here and make a one-time
> exception for this exceptional situation:
> 
> Please advise how you think we can get the NomCom eligibility
> question sorted out IN TIME to seat a 2020-21 NomCom, when we
> normally need to ask for volunteers within the next 6 weeks.

Barry,

I think I've suggested a variation on what follows off-list,
but, in response to your request:

(1) Write an I-D and get it posted (tomorrow would be good,
today better).  Focus it exclusively on the Nomcom eligibility
issue that has been under discussion on this list for weeks,
with more messages than I can easily count.  The shorter and
more narrowly-focused the draft is, the better (I think some
variation on Pete's draft is a good idea for multiple reasons,
but  this is not the time and doing it in haste would be
unwise.).  Obviously, you shouldn't ask me to write it :-)

Speaking as someone whose personal preferences are probably in
the rough, I don't particularly care which mechanism you choose
as long as the draft makes it clear that this is a one-time
thing to seat this (2020-2021) nomcom, that it cannot be used as
a precedent for the 2021-2022 nomcom or anything else, and that
it clearly and explicitly leaves 107 as a legitimate "First
Meeting" at which the new IAB and IESG were seated.  Beyond
that, I just don't believe that the number and profile of people
in the eligible pool are going to be significantly affected.  I
also believe that the number and profile of people from the
eligible poor who actually volunteer will be affected even less.
Those are anecdotal impressiona -- if any one has or can get
data one way or the other, let's see it, but let's not block on
waiting for it as having it show up in steps 3 or 4 below would
be ok.

(2) Provide in the I-D that it becomes effective the moment the
IESG approves it.  If there are appeals, we sort them out in
parallel with collecting Nomcom volunteers and seating them.  If
an appeal changes the rules in a way that affects someone, we
treat that as we treat any other situation in which a selected
volunteer is unable to serve.

(3) Give that I-D a week to season, nits to be picked, old
issues to be rehashed, etc.  If clear consensus emerges that
whatever mechanism that was selected for the -00 draft was the
wrong one, change the document (and make any other changes
suggested by the discussion) and get -01 posted.

(4) Issue a Last Call.   On the theory that we need four week
last calls only so the community has ample time to think about
an issue that has not been thoroughly vetted and refined in a WG
and noting that there is nothing substantive in the I-D (other
than "immediate effect on IESG approval") that has not been
kicked around (and around and around) on the IETF list for weeks
already, make a one-time exception and announce the Last Call
for two weeks, to be extended if discussions indicate that is
really needed.   That shortened time is a much smaller exception
that making an IESG decision about nomcom eligibility without a
document; it is consistent with the spirit of the 2026
provisions, and it should be a lot less controversial.

(5) The IESG agrees, internally and in advance, that the
document will be processed as soon as the Last Call ends, that
any AD who starts nitpicking (not that anyone would) will be
taken to the nearest bikeshed.   So either the IESG signs off,
with or without minor substantive adjustments, on whatever
emerges from the Last Call, or we need either a bigger bikesheed
or a distributed virtual one to accommodate all of us.

(6) At that point, three weeks and some days into your six, we
have an approved BCP and documented rough community consensus
for the rules for this Nomcom.  The RFC Editor gets to the
document in a timely fashion, but how quickly they do it does
not affect the process.

_Variation_

Skip Step 3, issue a four-week Last Call as soon as the I-D gets
posted, treat the comments that would have appeared during that
week as LC comments with the expectation of posting -01 halfway
through the LC period.   That avoids making any exceptions and
costs an extra week, but that is still less than the six week
window you suggest we have.

We could process Pete's document the same way, but the
"discussed for weeks" option wouldn't apply, so we'd need four
weeks to get it approved and _then_ a minimum of four weeks to
approve the variance, so, on your six week calendar, that just
doesn't work (as you have already noted).

Or we could dither around for three or four weeks and _then_ use
the shortness of time to justify the IESG making an executive
decision.  I hope (and expect) that we can all pull together on
this and skip that option.

best,
   john

(6)

(2) Twenty-four hours after the draft is posted

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 29 Mar 2020 09:19:30 +1300

An IESG Statement is how the IESG announces formal decisions that are outside the normal flow. "Exercise judgement" in English is a standard phrase, but the Collins dictionary entry says:

>> If you exercise something such as your authority, your rights, or a good quality, you use it or put it into effect.

When the IETF hits an urgent procedural problem that the written rules don't cover, it has always been the case that we expect the IESG to exercise its judgement after consulting the community. We have many precedents for that.

> Why is the above a problem for 2020/21?

That one out of the last five meetings was cancelled after many people had made their travel plans. That is not foreseen in the rules.
 
> in which volunteers are selected.

The NomCom Chair has not been appointed, and is subject to the same eligibility rules as the volunteer pool. At the moment, the ISOC President cannot appoint a chair because he cannot know who is eligible. So we are in a vacuum until the IESG exercises its judgement. (Which is why I don't think we should go the draft-resnick-variance route.)

Stay well,
    Brian

---

From: Keith Moore <[email-masked]>
Date: Sat, 28 Mar 2020 16:33:49 -0400

I support John's proposal for approving a one-time exception document to 
eventually be published as a BCP.

(I have more concerns about Pete's proposal.  IMO even if it's done at 
all, it should not be done hurriedly and should definitely not be a 
pacing item for making a one-time exception to nomcom eligibility rules).

Keith

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sat, 28 Mar 2020 16:37:52 -0400

> On Mar 28, 2020, at 4:19 PM, Brian E Carpenter <[email-masked]> wrote:
> 
…

> The NomCom Chair has not been appointed, and is subject to the same eligibility rules as the volunteer pool. At the moment, the ISOC President cannot appoint a chair because he cannot know who is e…

actually, there is a significant pool of people that qualify even if one assumes the the last meeting did or did not happen
(i.e. people who had been at 3 of the  4 meetings 103, 104, 105 & 106) you would lose some people that were at only 
two of those meetings and were at meeting 102 or meeting 107 (depending on how the decision comes out) but  the 
ISOC president could move ahead if he wanted to 

Scott

---

From: "Pete Resnick" <[email-masked]>
Date: Sat, 28 Mar 2020 15:50:48 -0500

On 28 Mar 2020, at 15:15, John C Klensin wrote:

> (I think some
> unwise.)

I have no problem putting that document on ice for a while. It was an 
attempt to come up with a way to avoid publishing a BCP for the 
2020-2021 NomCom (or any) variance. But it already sounds like people 
would want more time to ponder the limits of it or be convinced that 
it's actually a good idea, so it's unlikely to get published in time for 
it to make a difference.

I might publish an update today with the suggestions that people made so 
far, just to have it there if/when we want to get back to it, but I see 
no need to keep discussing it if it's not going to move through quickly.

pr

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 29 Mar 2020 09:56:57 +1300

> ISOC president could move ahead if he wanted to 

Well, that's not immune to challenge, which is why I believe that almost any choice that the IESG could make is fine, as long as it's notified to the ISOC Board. That wouldn't completely immunise against an appeal but would make an appeal highly unlikely to succeed.

Certainly if we can get a BCP out very quickly that would do fine, but it would have to be a very minimal BCP whose 4 week last call starts in the next week or two.
    Brian

---

From: S Moonesamy <[email-masked]>
Date: Sat, 28 Mar 2020 14:38:13 -0700

Hi Brian,
At 01:19 PM 28-03-2020, Brian E Carpenter wrote:
>An IESG Statement is how the IESG announces formal decisions that 
>are outside the normal flow. "Exercise judgement" in English is a 
>standard phrase, but the Collins dictionary entry says:
>
> >> If you exercise something such as your authority, your rights, 
> or a good quality, you use it or put it into effect.
>
>When the IETF hits an urgent procedural problem that the written 
>rules don't cover, it has always been the case that we expect the 
>IESG to exercise its judgement after consulting the community. We 
>have many precedents for that.

Thank you for the above explanation.

>That one out of the last five meetings was cancelled after many 
>people had made their travel plans. That is not foreseen in the rules.

Please see Scott's comments about the pool of people: 
https://mailarchive.ietf.org/arch/msg/ietf/gPz7XTo8y0drqb6Wgs9zKrJ0QBU/

>The NomCom Chair has not been appointed, and is subject to the same 
>eligibility rules as the volunteer pool. At the moment, the ISOC 
>President cannot appoint a chair because he cannot know who is 
>eligible. So we are in a vacuum until the IESG exercises its 
>judgement. (Which is why I don't think we should go the 
>draft-resnick-variance route.)

There is already a pool of eligible persons irrespective of whether 
the last meeting happened or not.

At 01:56 PM 28-03-2020, Brian E Carpenter wrote:
>Well, that's not immune to challenge, which is why I believe that 
>almost any choice that the IESG could make is fine, as long as it's 
>notified to the ISOC Board. That wouldn't completely immunise 
>against an appeal but would make an appeal highly unlikely to succeed.

Nobody raised a concern about being ineligible if that last meeting 
is not taken into consideration.  The number of appeals over the last 
few years is a single digit number.  The number of appeals which 
could be viewed as successful is very low.  I would worry too much 
about designing a vaccine against challenges.

Regards,
S. Moonesamy

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 29 Mar 2020 10:24:12 -0500

> it's actually a good idea, so it's unlikely to get published in time for

I was somewhat surprised that this draft went beyond the immediate question
of 2020/2021 Nomcom eligibility, so if we address only that question as a
one-time exception, and then return to the general question, I'd be ok with
that.

It's worth looking carefully for any other weirdness that may be
problematic here - my favorite is that the IESG is seated at the First IETF
meeting of the year, and it's not at all clear that virtual IETF 107 would
meet the letter of the law if anyone decides to appeal that decision. (
https://tools.ietf.org/html/rfc7437#section-1)

I wouldn't be surprised if there are other implications that should be
cleaned up, whether as another one-off BCP or using whatever Pete's draft
turns out to be.

Make good choices, of course.

Best,

Spencer

---

From: Michael Richardson <[email-masked]>
Date: Sun, 29 Mar 2020 12:14:13 -0400

Pete Resnick <[email-masked]> wrote:
    >> it's never a great idea to hurriedly invent new process when doing so can
    >> be avoided.

    > all of

I read it now.

    > 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.

I would be happier if the variance was recorded as more than an Internet-Draft.
I understand the desire not to issue an RFC/BCP, and certainly not to wait
for the RFC-EDITOR to process it.  I suggest that the errata process be used.

In particular, should the document ever get revised, then the one-time
variance would get recorded as an appendix.  If any other RFCs were published
as a result of the variance (i.e. if the variance was a suspension of some other
publication rule), then those documents would need to indicate this case.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 29 Mar 2020 12:22:15 -0400

On Sun, Mar 29, 2020 at 11:24 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> I was somewhat surprised that this draft went beyond the immediate
> question of 2020/2021 Nomcom eligibility, so if we address only that
> question as a one-time exception, and then return to the general question,
> I'd be ok with that.
>
>
I think having the variance short lived makes sense and allows us to both
deal with the immediate situation and give us some time to close any
process or documentation gaps.

regards,

Victor K

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Mar 2020 08:40:49 +1300

On 30-Mar-20 05:22, Victor Kuarsingh wrote:
> 
> 
> On Sun, Mar 29, 2020 at 11:24 AM Spencer Dawkins at IETF <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
>     On Sat, Mar 28, 2020, 15:51 Pete Resnick <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     I was somewhat surprised that this draft went beyond the immediate question of 2020/2021 Nomcom eligibility, so if we address only that question as a one-time exception, and then return to the general question, I'd be ok with that.
> 
> 
> I think having the variance short lived makes sense and allows us to both deal with the immediate situation and give us some time to close any process or documentation gaps. 

Sure, but we could do a one-time variance as a BCP inside 6 weeks if people are sensible. (A few days to draft it, 4 week last call, a few days to finalise the text, run the IESG ballot, and one-day turnaround at the RFC Editor.) We are supposed to be a can-do organisation.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Sun, 29 Mar 2020 16:00:57 -0400

> Sure, but we could do a one-time variance as a BCP inside 6 weeks if people are sensible. (A few days to draft it, 4 week last call, a few days to finalise the text, run the IESG ballot, and one-da…

Yeah, it seems like we already have a very straightforward and 
well-established procedure for doing this, i.e. publishing a BCP, and 
people keep proposing alternatives that take more time and effort and/or 
have a greater chance of being called into question.

Let's just do this.

Keith

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 29 Mar 2020 14:07:19 -0700

> for the RFC-EDITOR to process it.  I suggest that the errata process be used.

I'm confused at how the errata process would even be used for this
(discounting for the sake of argument that it would be a clear abuse of the
errata process)...

-Ben

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 29 Mar 2020 17:17:32 -0500

Well, if you think that "can do organizations" need to Do The Right Thing
from time to time. ...

On Sun, Mar 29, 2020 at 2:41 PM Brian E Carpenter <
[email-masked]> wrote:

> Sure, but we could do a one-time variance as a BCP inside 6 weeks if
> people are sensible. (A few days to draft it, 4 week last call, a few days
> to finalise the text, run the IESG ballot, and one-day turnaround at the
> RFC Editor.) We are supposed to be a can-do organisation.
>

If you get as far as an AD requesting IETF Last Call, which is still what
we do for maximum visibility in the community, what would it take (in this
specific case) to start working toward implementing the workaround, and
assuming that you're either Doing The Right Thing, or that Last Call will
blow up quickly, and you'll know you should wait for the responsible AD to
provide further direction? Even at that point, if the emergency action is a
horrible plan, the decision to request Last Call, or to move forward
optimistically, can be appealed, Now that I think about it, the decision to
move forward optimistically should be included in the Last Call
announcement.

If something is an emergency, ISTM that including "and then we wait four
weeks" is not a great way to respond to an emergency.

If it's not an emergency, we have all the BCPs we need to guide us
(especially if we tweak https://tools.ietf.org/html/rfc3933 with a view to
moving faster than seemed necessary in 2004).

But Make Good Choices, of course.

Best,

Spencer

p.s.  I haven't worked on a lot of BCPs, but I've worked on enough to know
that trying to predict corner cases in advance is hard (and tends to give
you a fair amount of text that's not helpful when you need it). Can we not
tweak the plan for Nomcom 2020/2021 until it's too late to use it?