Subject: [RFC 3777 Update for Vacancies]

From: Bob Hinden <[email-masked]>
Date: Wed, 24 Oct 2012 09:14:10 -0700

The draft that proposes changes to the RFC3777/BCP10 to deal with vacancies is now available.

  http://tools.ietf.org/html/draft-ietf-genarea-bcp10upd-00

Bob

--------------------

From: [email-masked] 
To: [email-masked] 
Reply-to: [email-masked] 
Subject: I-D ACTION:draft-ietf-genarea-bcp10upd-00.txt 
X-C5I-RSN: 1/0/935/46939/50333 
 
A new Internet-Draft is available from the on-line Internet-Drafts directories. 
 
Title : RFC 3777 Update for Vacancies 
Author(s) : D. Crocker, et al 
Filename : draft-ietf-genarea-bcp10upd 
Pages : 4  
Date : Oct. 24, 2012  
 
BCP 10 (RFC 3777) specifies IETF processes for selection, 
confirmation and recall of appointees to IETF positions. It also 
refers to the mechanism of resignation as part of a sequence that 
moves a sitting member to a new IETF position. However it does not 
more generally deal with vacancies created by resignation, death or 
uncontested, sustained absence from participation. This update to 
BCP 10 specifies procedures for handling vacancies. 
 
A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-ietf-genarea-bcp10upd-00.txt 
 
Internet-Drafts are also available by anonymous FTP at: 
ftp://ftp.ietf.org/internet-drafts/

---

From: Barry Leiba <[email-masked]>
Date: Wed, 24 Oct 2012 16:22:08 -0400

>   http://tools.ietf.org/html/draft-ietf-genarea-bcp10upd-00
Two comments:

1 (nit):
   For vacancies due to death or resignation, no further action is
   required, to declare the seat vacant.

Remove the second comma.

2:
   For vacancies due to uncontested, sustained absence, the IETF body
   making that determination will issue an Extended Last Call to the
   community.

Where is "Extended Last Call" defined?  There should be a citation thither,
or a definition here.

I think this is a fine proposal, and I support it and hope the community
will show consensus for it.

Barry

---

From: "Bradner, Scott" <[email-masked]>
Date: Wed, 24 Oct 2012 20:25:03 +0000

On Oct 24, 2012, at 4:22 PM, Barry Leiba <[email-masked]>
 wrote:

> Where is "Extended Last Call" defined?  There should be a citation thither, or a definition here.

RFC 2026 section 9.1

   The proposed variance must detail the problem perceived, explain the
   precise provision of this document which is causing the need for a
   variance, and the results of the IESG's considerations including
   consideration of points (a) through (d) in the previous paragraph.
   The proposed variance shall be issued as an Internet Draft.  The IESG
   shall then issue an extended Last-Call, of no less than 4 weeks, to
   allow for community comment upon the proposal.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 24 Oct 2012 16:27:16 -0400

>    allow for community comment upon the proposal.

Indeed.  And (1) "Extended Last Call" <> "extended Last-Call" and (2)
there's no citation to 2026.

b

---

From: David Morris <[email-masked]>
Date: Wed, 24 Oct 2012 13:45:53 -0700 (PDT)

I see several issues .... 

a) To my reading RFC 3777 only deals with IAB and IESG membership
b) Neither this draft nor 3777 defines 'IETF body' 
c) Consindering that someone would be a member until removed, and
   assuming IAOC is meant to be considered an IETF body, 2/3 of
   members approving could be sticky at some point if 2/3 of
   the members aren't available to vote.
d) We need a better definition of 'sustained' absence ... e.g., 
   a minimum period of time, number of regularily scheduled
   'meetings' missed, no response to queries.
e) "Multiple different queries" ... needs more precision as it
   is satisfied as stated by 2 emails sent at the same time to
   the same destination. This section may require an adjustment
   to the sort of contact information required for each position
   covered by this process.

Dave Morris

---

From: Barry Leiba <[email-masked]>
Date: Wed, 24 Oct 2012 17:05:12 -0400

> a) To my reading RFC 3777 only deals with IAB and IESG membership

RFC 4071 (BCP 101) specifies use of the 3777 recall process for the IAOC.

> b) Neither this draft nor 3777 defines 'IETF body'

Simply making Section 3.1 say 'the IAB, IESG, or IAOC ("an IETF body")'
will take care of that.

>    the members aren't available to vote.

I presume you mean, "if there aren't 2/3 of the members available to vote."
 Yes, well, true.  But then there's always the recall process to fall back
on.

>    to the sort of contact information required for each position

Both of these are handled by giving the IETF body some judgment,
counterbalanced by the ability to contest it.  If the judgment is
uncontested, we're fine.  If it is contested, then we go back to the recall
process.  I think that's a fine approach, and would NOT like to overspecify
this.

Barry

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Oct 2012 08:22:30 +0100

>>   http://tools.ietf.org/html/draft-ietf-genarea-bcp10upd-00
...
> will show consensus for it.

+1.

However, I suggest that "For a contested, sustained absence,..." is
a little unclear. I suggest

   If the member concerned contests the determination that they have
   vacated the position, the existing Member Recall process, as specified
   in Section 7 of [RFC3777], is required.

(This contest could occur during the Last Call.)

     Brian

---

From: Barry Leiba <[email-masked]>
Date: Thu, 25 Oct 2012 09:23:37 -0400

Bob, Russ... repeating here what I said in the other thread, I suggest
that...

- the authors of  draft-ietf-genarea-bcp10upd post an -01 version TODAY,
incorporating comments received so far,

- Russ, as Gen AD, immediately issue a formal (4 week) last call on that
version, and

- the document be put on he 29 November IESG telechat for approval.

If we do that, unless something odd happens we will have this process
update formally approved BY OUR PROCESS in five weeks.

Let's please not delay.

Barry

---

From: John C Klensin <[email-masked]>
Date: Thu, 25 Oct 2012 11:03:26 -0400

--On Thapparently-strongly-held ursday, October 25, 2012 09:23
-0400 Barry Leiba <[email-masked]> wrote:

> Bob, Russ... repeating here what I said in the other thread, I
> suggest that...
> 
> - the authors of  draft-ietf-genarea-bcp10upd post an -01
> version TODAY, incorporating comments received so far,
> 
> - Russ, as Gen AD, immediately issue a formal (4 week) last
> call on that version, and
> 
> If we do that, unless something odd happens we will have this
> process update formally approved BY OUR PROCESS in five weeks.
> 
> Let's please not delay.

Barry,

I really, strongly, object to this way of proceeding.   Making
fundamental procedural changes in haste and in the middle of a
perceived crisis is never a good idea for any organization.  My
experience leads me to believe that IETF is even less good at it
than average, but, even if your experience differs, it still
isn't a good idea.  Doing it right now is particularly bad
because, despite the many postings on the list, a significant
fraction of the community is (and should be) focused on
preparation for the technical work of the IETF meeting or on
clearing up other work so that they can attend, not on
discussion of a procedural change that appeared in a late-posted
draft.   A four-week Last Call offers some protection against
that but maybe not enough (I note that the IESG has often
required longer-than-minimum Last Call periods when the Last
Call spans IETF meetings and/or major holidays).

In addition, making a procedural change to deal, effectively
retroactively, with a problem that is already in progress simply
has a bad, ex post facto, odor about it, an odor I believe we
should not ignore.

Let's deal with the matter at hand and the associated perceived
emergency and then, after the dust has settled, go back and
review procedures.  If you want a more pragmatic argument than
the "bad idea to rush through a procedure change" one above,
consider that your desired fast schedule could be entirely
derailed by _one_ member of the community waiting until the IESG
votes and then lodging an appeal whose substance is that, if the
IESG can change procedures in this way to change the rules as
applied to a particular situation, especially one related to a
personnel matter, that predated the change, it makes fairness
impossible.  

While I disagree with most of them, I've seen enough comments on
the list to the effect that, if recall is the only option we
have, we need to use it -- comments based on principles that are
apparently strongly-held by those making them-- to believe that
such an appeal is not entirely unplausible**.  (And my apologies
if I'm giving anyone ideas they didn't have already.)

So let's solve the present problem using good sense and the
tools at hand.  

>From my personal point of view, either of the following would be
rational, consistent with good sense, and just about as fast as
your proposal:

(i) If the IAOC is unanimously (obviously less Marshall)
convinced that everything plausibly possible has been done to
try to get a response from Marshall and that that there is no
reasonable possibility that he is unaware of the situation, then
a conclusion that he has resigned by his silence would seem to
be in order.  Personally, I'd like to see that in a resolution
in which the steps taken are reviewed, the unanimity is
recorded, and the resignation is noted.  I'd prefer to see that
resignation noted as "presumably for personal reasons" as well,
rather than "deeming the position vacant" because I would prefer
that we not hint at anger at Marshall in the record.  But, if
those distinctions are too subtle for the IAOC. so be it.

(ii) The IESG could use its implied authority to interpret RFC
2026 (an authority it has at least implicitly applied many times
in the past).  It could interpret the 2026 variance procedure as
applying to all bodies to which 2026 applies, whether they were
created earlier enough to be enumerated in 2026 or not.  (FWIW,
I personally believe that interpretation would be correct
relative to the intentions 16 years ago.)  That procedure could
then be used to treat the current situation as a resignation
without creating any unfortunate precedents.

While either of those approaches could be appealed as well, it
would be far harder to create a plausible claim of unfairness
in/to the community.  Indeed, it might be that only Marshall or
someone plausibly acting on his behalf, could reasonably appeal
and, if that were to occur, the real problem of non-response
would presumably disappear. 

I think other approaches are plausible too.  I hope we can avoid
the recall procedure, not because it would take a long time but
because it involves a level of condemnation of Marshall that I
believe that, in the light of past contributions, we should
bypass if possible.   Given the number of years we have gone
without ever exercising the recall procedure, I'd rather reserve
"first person ever recalled" for someone who has misbehaved in
some rather nasty way and I'm not convinced that Marshall
qualifies.  But even it would be better than trying to make a
significant and permanent procedural change on a "let's see if
we can do it before the end of November and then retroactively
apply it to this problem" basis.

best,
   john

** I've used "plausible", "rational", and their synonyms several
times in this note to stress the principle that the IETF should
continue to favor good sense and consensus over rigid rules and
their more rigid consideration.  If we cannot continue to do
that, I believe we are lost because our procedures are not
nearly good enough (or updated carefully enough every time
something changes) to sustain a rigid adherence to the letter of
the rules and nothing else.

---

From: John Leslie <[email-masked]>
Date: Thu, 25 Oct 2012 11:24:05 -0400

John C Klensin <[email-masked]> wrote:
> perceived crisis is never a good idea for any organization.

   I don't agree this is a "fundamental" procedural change. Barry
would like to start a four-week last call on a procedure change
to which I haven't heard any objection -- just a lot of discussion
on whether it's needed and whether it might apply to the current
situation.

   IMHO it's needed, precisely because of the current disagreement
on this list.

   Also IMHO, it doesn't apply to the current situation. This will
either have resolved itself in five weeks or it won't. If 20 folks
petition for recall, recall procedure will be followed. If this
issue dies down with folks consenting to the NomCom filling the
vacancy, it will be filled.

   If, OTOH, in five weeks it hasn't died down, we could _start_
another four-week LastCall on whether there is a vacancy, based
on five more weeks of inactivity than we already have.

   If, during the next four weeks, further suggestions are made to
the process to be used going forward, they can be incorporated
before it's adopted.

   For myself, I'm willing to let this fester longer if it is indeed
the consensus of the IETF to let it fester. But I find Barry's
proposal entirely reasonable. (And I have to stop here, to be set up
for scribing today's IESG telechat.)

--
John Leslie <[email-masked]>

---

From: John C Klensin <[email-masked]>
Date: Thu, 25 Oct 2012 12:22:15 -0400

--On Thursday, October 25, 2012 11:24 -0400 John Leslie
<[email-masked]> wrote:

>    I don't agree this is a "fundamental" procedural change.
> Barry would like to start a four-week last call on a procedure
> change to which I haven't heard any objection -- just a lot of
> discussion on whether it's needed and whether it might apply
> to the current situation.

John,

I'm not going to debate this and will now go back to
intermittent lurking because I've got too much other work to do
right now if I'm going to get to IETF.  However: 

-- The community has had significant experience with procedural
changes having unexpected consequences or side effects that then
have to be corrected or worked around.  I suggest that
experience implies that _any_ change to basic procedures should
be treated as fundamental and considered on that basis until the
community is satisfied that it actually covers the cases it is
intended to cover and nothing else.

-- While you may interpret "haven't heard any objection" as
agreement, I suggest that, for a late-posted draft at this time
of year, it could as easily be "silence from people whose
priorities haven't allowed sufficient opportunity to study the
proposal and comment".

best,
   john

---

From: SM <[email-masked]>
Date: Thu, 25 Oct 2012 13:11:31 -0700

Hi John,
>without creating any unfortunate precedents.

Yes.

RFC 4333 could also be used:

   "if the appointed member is unable to serve the full two-year term,
    the selecting body may, at its discretion, immediately select a
    replacement to serve the remainder of the term using the interim
    process defined in Section 3.5.1."

Please note that a member recall requires a signed petition by at 
least 20 people.  It does not require the approval of the IAOC or the 
IESG.  As such, nobody is stopping anyone from doing that.

Regards,
-sm

---

From: Scott O Bradner <[email-masked]>
Date: Thu, 25 Oct 2012 18:08:23 -0400

> without creating any unfortunate precedents.

for some additional context about the variance procedure - it originally 
came from RFC 1871

Scott

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Oct 2012 14:23:17 +0200

Bob,

I've read through the draft, and would prefer a different approach. 
Since we already have a recall procedure for contested removals, this
draft should focus itself on uncontested removals, and really just
*absense*.  How do you test if something is uncontested?  Easy enough:
ask the IETF community.  If a single person objects, let's call that
"contested" and go with the other procedure.

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Fri, 26 Oct 2012 10:29:30 -0400

I've read the draft.  I think its the wrong approach, mainly because its focusing on the current problem rather than a new mechanism.

In general, I know of 5 ways an elected or appointed position may become vacant:  resignation, death, incapacity, recall or expulsion.

We currently have mechanisms in place for 3 of the 5.  I'm not sure at this point how to deal with incapacity, and I think it can actually be handled (except possibly for the IETF chair) under recall or expulsion or resignation.  (There's also removal for appointees where the appointing entity has removal rights).

I'm using "expulsion" here the way its used in the US political system - a legislative body may choose to expel one of its members for various reasons.  I propose that we define such a mechanism for the IETF bodies.

See below. 

And I'm not proposing that this be adopted in a hurry to fix the current problem.  

Mike

_____________________________________________________
Expulsion - General:

Members may be expelled from the bodies to which they belong by votes of other members of those bodies.  The expelling bodies need not give or have any public reason for the expulsion, but should consider the impact on the standards process prior to proceeding with the expulsion.

Expulsion - the IETF chair:

The IETF chair is not subject to expulsion.  In the event the IETF chair is not available, and at the request of 2/3 of the remaining voting members of the IESG, the ISOC President shall appoint a temporary replacement with the advice and consent of the IAB who shall serve until the end of the IETF chair's term whenever the IETF chair is unavailable.  The recommendation is that a former IETF or IAB chair be appointed if available.  The replacement serves at the pleasure of the ISOC president and may be replaced if, in the sole judgement of the ISOC president, replacement is required.

Expulsion of liaison members:

If 2/3 of the voting members (minus the liaison member in question if that member is a voting member) concur, the liaison member is expelled and the appointing organization shall appoint a replacement.  A member not subject to removal by their appointing body is not considered a liaison member for the purposes of this section.

Expulsion of all other members.

If 2/3 of the voting members (minus the member in question, if that member is a voting member) concur notice shall be sent to the appropriate IETF mailing lists.  The notice shall be repeated three times with a two week interval between each notice.  The notice shall indicate the intent to expel the member and shall request the member show cause to the confirming body as to why the expulsion should not occur.

One week after the last notice, the appropriate confirming body (e.g. IAB for IESG, IESG for IAOC, etc), shall consider the expulsion request and any response given by the member.  If 2/3 of the voting members of the confirming body concur, the member shall be removed and the position be considered vacant.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Oct 2012 17:02:41 +0200

> I'm using "expulsion" here the way its used in the US political system - a legislative body may choose to expel one of its members for various reasons.  I propose that we define such a mechanism fo…

Why should bodies have this right?

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Fri, 26 Oct 2012 11:11:52 -0400

>Why should bodies have this right?

I'm not saying they should - but that seems to be what Bob et al are asking for.  Doing it this way means you don't have to reach to questions of what constitutes an "absence" or "abandonment" - subjective judgements.

If someone pisses his fellow members off sufficiently that they can't work with him/her for whatever reason you have this.

And it's still subject to veto by the confirming body, so the expulsion reasons will have to be pretty egregious to get through two votes of 2/3. 

Mike

---

From: John C Klensin <[email-masked]>
Date: Fri, 26 Oct 2012 11:39:48 -0400

--On Friday, October 26, 2012 11:11 -0400 Michael StJohns
<[email-masked]> wrote:

>>> I'm using "expulsion" here the way its used in the US
>>> political system - a legislative body may choose to expel
>>> one of its members for various reasons.  I propose that we
>>> define such a mechanism for the IETF bodies.
>>> 
>> 

> I'm not saying they should - but that seems to be what Bob et
> al are asking for.  Doing it this way means you don't have to
> reach to questions of what constitutes an "absence" or
> "abandonment" - subjective judgements.
> 
> If someone pisses his fellow members off sufficiently that
> they can't work with him/her for whatever reason you have this.
> 
> And it's still subject to veto by the confirming body, so the
> expulsion reasons will have to be pretty egregious to get
> through two votes of 2/3. 

Mike,

This is exactly the sort of path I don't want to go down, at
least without a lot of consideration of its possible
implications.  Remember that the community has refused to even
let IAB or IAOC members sign/endorse a recall petition against
one of their own number and that process provides far better
checks against abuses or personality problems than any "expel
member" plan, even with a requirement for confirming body
signoff.

It is possible for someone to be in a tiny minority (perhaps of
one) in those bodies, thoroughly irritate everyone else about
positions, and still be acting in the best interests of the
community, maybe even reflecting community consensus.  Having
watched a number of IABs from the inside, I wouldn't count on
them, and much less on the ISOC BoT, to say "no" to an internal
membership management request from the IESG or IAB respectively.
There have been exceptional years, but the general instinct in
matters that are really internal to how the other body functions
is to defer to that body on the grounds that they know what they
need.

In principle, I have no problem with setting up a list of
repeated/ long-term non-feasance, non-appearance, or
non-responsiveness conditions that are treated as equivalent to
a more formal resignation unless the body of which that person
is a member votes to waive the rule (i.e., not accept the
resignation).    I actually think that would be completely
reasonable and that we probably should have established such
principles years ago even though I'd expect a lot of quibbling
about setting the thresholds for "repeated/ long-term".

But I believe we should not design things around this particular
case or create the perception that we are doing so by changing
processes while the case is still open.  Indeed, I think
fairness dictates that people should know about such rules and
their implications at the time they accept nomination for a
position -- it becomes part of what they are signing up for --
rather than applying such a rule to today's incumbents.

best,
   john

---

From: Michael StJohns <[email-masked]>
Date: Fri, 26 Oct 2012 12:25:05 -0400

>about setting the thresholds for "repeated/ long-term".

This is exactly what I'd like to avoid.  No matter how we set the conditions, someone will argue - successfully - that the conditions are not met.  (For example, I attend one out of every 3 meetings for exactly 5 minutes - I obviously haven't abandoned the position, but I really have abrogated my responsibilities).  Etc etc etc etc etc... 

Or something will come up that the conditions just never anticipated (the current example springs to mind).

Let the bodies decide if the member is doing their job.  If 2/3 of them think no and they can convince 2/3 of the confirming body, then its time for him to go.  This handles pretty much any "emergency" condition I can think of and does it in only a little more than a month.  And note, that unlike a recall, there is no bar to being re-appointed by the Nomcom in the following term.

The recall process remains for the body of the IETF to be able to affect a removal with some amount of formalism.

I'm pretty much going to object to any condition based model that anyone proposes, because we're really bad at a) figuring out the complete list of all possible conditions that could ever happen, b) writing conditions that can be objectively evaluated, and c) figuring out how to decide when specific conditions are met (because of the lack of objective criteria).  In addition, people have been carping on the mailing list about how we need to be flexible - and condition lists by their very nature are not flexible.

---

From: John C Klensin <[email-masked]>
Date: Fri, 26 Oct 2012 13:16:15 -0400

--On Friday, October 26, 2012 12:25 -0400 Michael StJohns
<[email-masked]> wrote:

>...
> I'm pretty much going to object to any condition based model
> that anyone proposes, because we're really bad at a) figuring
> out the complete list of all possible conditions that could
> ever happen, b) writing conditions that can be objectively
> evaluated, and c) figuring out how to decide when specific
> conditions are met (because of the lack of objective
> criteria).  In addition, people have been carping on the
> mailing list about how we need to be flexible - and condition
> lists by their very nature are not flexible.

Mike,
Oddly, while I disagree with your conclusion, I agree with the
above.  The difference is that I don't expect an "if X, then you
resigned" condition-based model to work very well in the edge
cases and where someone was trying to game the system.  It can't
work well for the edge cases for all the reasons you list,
especially because we are lousy at anticipating all possible
cases and writing rules to match.

More specifically, I'm ok with a procedure that works well when
someone just disappears and stops performing -- a problem that I
think has arisen around three times in the last 20 years.  I'm
also ok with the fact that such a procedure probably would not
have worked for one of them and that it would fail any time an
incumbent chose to fight expulsion, whether by stunts like "one
out of every 3 meetings for exactly 5 minutes" or by nit-picking
the rules.

My only interest is to help these who, for one reason or other,
have already slunk away into the night or otherwise disappeared
make a graceful and efficient exit.    That is an entirely
different case from someone who is not performing  but who
actively wants to hold onto the job.

For the latter cases --if someone is intentionally gaming the
system or resisting expulsion or resignation in other ways-- I
think the recall procedure, and all of the public unpleasantness
and condemnation that go with it, is exactly right and that
nothing new is needed (although see below).  It doesn't let a
body determine its own membership (if we don't want IESG or IAB
members, even retiring ones, voting on the Nomcom because we are
afraid of self-perpetuating bodies, we certainly shouldn't let
them second-guess Nomcom decisions by ejecting members without
any review external to the I* leadership).

If someone is non-performing and being a jerk about it (and
maybe just consistently being a jerk), I think it would be
reasonable to let a supermajority of the relevant body initiate
(and fast track the beginning of) a recall, but I note that the
community has rejected less drastic ideas in the past.

  best,
   john

---

From: Eric Burger <[email-masked]>
Date: Sun, 28 Oct 2012 13:31:18 -0400

Echoing John here, he very succinctly explains why setting out clear lines of what does or does not constitute abandonment invites abuse.

If someone is acting against the interests of the IETF, we have lots of ways of dealing with it.

If someone falls off the face of the Earth, and repeated attempts to contact them using legally recognized methods of notice fails, and more importantly they have a positive track record that spans over a decade, we can use our existing nomcom tools to replace their nomcom-appointed duties. I would offer that a person in such a position with such demonstrated dedication would not want us to do otherwise.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 29 Oct 2012 14:06:58 +0100

Bob, everyone,

As I've mentioned, I'd prefer an alternative to what the authors have
written.  Call this the "let's program ourselves out of a paper bag"
option, when we all agree.  This may be a rule we would wish to
generalize.  Here is the basis for what I propose:

 1. We have existing procedures to resolve contested removals – the
    recall process.
 2. "Uncontested" essentially means that we as a community are in
    unanimous agreement that the position is vacant.  That means that by
    definition, any "no" votes from a body means it's contested.
 3. The least amount of power should be delegated to our bodies as is
    necessary for the organization's smooth operation.
 4. Procedural arguments on the IETF list are tiresome, when we all
    agree on the right outcome ;-)

With that in mind, I've attempted to reduce changes to a more simplified
form, as follows:

In draft-ietf-genarea-bcp10upd-00.txt, Section 3.3, 2nd and 3rd paragraphs,

OLD:

   For vacancies due to uncontested, sustained absence, the IETF body
   making that determination will issue an Extended Last Call to the
   community.  The Last Call will explain the basis for declaring the
   position vacant and include a summary of efforts to contact the
   member to resolve the issue.

   The results of the Last Call are assessed by the IETF body, with a
   two-thirds vote of the body.

NEW:

    When an IETF body unanimously believes that a position on that
    body has been vacated, they may request confirmation of this by
    the community through an Extended Last Call with their reasoning.
    Should no objections be received during that period, the position is
    said to be vacant.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Mon, 29 Oct 2012 09:58:48 -0400

--On Monday, October 29, 2012 14:06 +0100 Eliot Lear
<[email-masked]> wrote:

> Bob, everyone,
> 
> As I've mentioned, I'd prefer an alternative to what the
> authors have written.  Call this the "let's program ourselves
> out of a paper bag" option, when we all agree.  This may be a
> rule we would wish to generalize.  Here is the basis for what
> I propose:
> 
>  1. We have existing procedures to resolve contested removals
> – the     recall process.
>  2. "Uncontested" essentially means that we as a community are
> in     unanimous agreement that the position is vacant.  That
> means that by     definition, any "no" votes from a body means
> it's contested.  3. The least amount of power should be
> delegated to our bodies as is     necessary for the
> organization's smooth operation.  4. Procedural arguments on
> the IETF list are tiresome, when we all     agree on the right
> outcome ;-)
> 
> With that in mind, I've attempted to reduce changes to a more
> simplified form, as follows:
>...
> NEW:
> 
>     When an IETF body unanimously believes that a position on
> that     body has been vacated, they may request confirmation
> of this by     the community through an Extended Last Call
> with their reasoning.     Should no objections be received
> during that period, the position is     said to be vacant.

Eliot,

I generally like the general direction in which you are headed.
On other other hand, your specific proposal creates an
opportunity for a single individual, perhaps even one who
follows the mailing list but who is not an active participant in
the IETF or who just doesn't like the procedure, to disrupt
things and throw us back on recalls.   Given the number of
occasionally-grumpy people in the extended community, that does
not seem wise.

Quick thought and strawman suggestion: how about we take your
general model, but instead of using the absence of any
objections as the "not vacant, requires recall" trigger, perhaps
we could borrow a little bit from the recall model.  For
example, we might say that deciding that the procedure doesn't
apply when the body thinks the position is vacant requires a
petition endorsed by some number of people.  The "20" of the
recall procedure seems a bit high to me, but you get the general
idea.  One person claiming the position isn't really vacant
could be just a grump; ten or twenty probably indicates that
something odd is going on and a more heavyweight procedure is
required.

   john

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 29 Oct 2012 10:00:51 -0400

> occasionally-grumpy people in the extended community, that does

+1

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Eric Burger <[email-masked]>
Date: Mon, 29 Oct 2012 10:01:29 -0400

Sounds reasonable to me.

---

From: John C Klensin <[email-masked]>
Date: Mon, 29 Oct 2012 10:39:20 -0400

--On Sunday, October 28, 2012 13:31 -0400 Eric Burger
<[email-masked]> wrote:

> If someone falls off the face of the Earth, and repeated
> attempts to contact them using legally recognized methods of
> notice fails, and more importantly they have a positive track
> record that spans over a decade, we can use our existing
> nomcom tools to replace their nomcom-appointed duties. I would
> offer that a person in such a position with such demonstrated
> dedication would not want us to do otherwise.

IMO, Eric's last sentence above is exactly the essence of why I
think a lightweight (and different-from-recall) procedure is
needed.  Suppose we have a long-standing positive contributor,
or even someone who took a high-responsibility position in good
faith but then discovered that he or she was seriously in over
their head.  That person responds to conditions beyond our
control (and maybe beyond theirs) by disappearing and not
responding to attempts to get them to clarify things.  Whatever
is causing those symptoms, we probably do both the community and
the person involved a favor by replacing them and moving forward
without making a huge fuss about it.   There have to be
safeguards, but there don't need to be formal accusations of
malfeasance.

Coming back to the note from which Eric quoted, none of the
above has anything to do with someone who is consistently
behaving like a jerk -- whether by participation or
non-participation (including active attempts to resist vacancy
claims when they aren't doing anything).  For those situations,
the determination of whether a sufficient level of jerk-like
behavior has been achieved to justify expulsion needs to be made
by the community, not by irritated fellow members of the
affected body.  Our presumption is that recall is a perfectly
adequate mechanism for that purpose.  If it isn't, we should fix
it, but it has nothing to do with the case described above.

   best,
   john

---

From: [email-masked]
Date: Mon, 29 Oct 2012 21:18:00 +0000

+1
 
Regards,
 
Ed  J.
 
-----Original Message-----
From: Donald Eastlake <[email-masked]>
Sender: [email-masked]
Date: Mon, 29 Oct 2012 10:00:51 
To: Eliot Lear<[email-masked]>; John C Klensin<[email-masked]>
Cc: IETF list<[email-masked]>
Subject: Re: [RFC 3777 Update for Vacancies]

+1

Thanks,
Donald