Subject: Re: don't overthink, was Just so I'm clear

From: [email-masked] (Noel Chiappa)
Date: Thu, 25 Oct 2012 08:53:51 -0400 (EDT)

> From: David Morris <[email-masked]>

    > someone unsatisfied with a business decision by the adjusted IAOC
    > membership could sue based on documented process not being followed to
    > appoint the membership.

Nothing can stop someone from filing a suit, no matter what you do (even if
you do follow procedure). But try looking at it this way.

We're all agreed that the IETF in plenary mode (i.e. all of us) can change
any/all policy/procedures, right?

So, view the original call from the IAOC as a request to the IETF, in formal
plenary mode, to make the following policy/procedure changes/etc:

- To declare that, due to an oversight on our part at the time of drafting,
our existing policy/procedure does not handle certain cases, so we are
_temporarily_ (see below) setting up an ad hoc procedure to handle those
cases;

- That said temporary ad hoc procedure is to have the IETF in plenary mode
decide/declare that positions are vacant due to the withdrawal of the holder.

The call also make the following procedural request:

- That, following that temporary ad hoc procedure, in the particular case in
the original call, the holder be declared to have vacated, due to his long
lack of communication, despite _extensive_ attempts to contact him.

So if people all hum to OK all that, it has _just as much legitimacy_ as
_any other policy/procedure set into place by the IETF in plenary mode_.

And of course we all recognize that we need to write down non-ad hoc
policy/procedure to handle such cases, an effort which has already started.

    > From: "John Levine" <[email-masked]>

    > Having reread RFC 4071, I don't see a rule that says that the death of
    > a member will result in the position being declared vacant, either. Nor
    > are there any rules that say what documentation would be required to
    > establish that someone had died.

    > At some point we have to allow a sliver of common sense to intervene so
    > people can do reasonable things to solve problems.

Exactly.

I'm really boggled at the amount of time and energy which has been wasted
arguing about this point. Don't we have better things to spend our time on?

It's pretty clear he's checked out, and needs to be replaced. We ought to
focus on the most economical way to achieve that purely bureacratic action.

	Noel

---

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

> any/all policy/procedures, right?

...

> _any other policy/procedure set into place by the IETF in plenary mode_.

Alas, that's not how we do things.  We have a process, and we need to
follow it.  Anything else does NOT have legitimacy.

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.

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

Barry

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 Oct 2012 15:37:29 +0100

Barry,
 
If you believe that a change to process is necessary to make a ruling on
absentee-ism, then you will also (on reflection) believe that process changes
cannot be made retro-active.
 
So, rushing this through (I do not mean to be pejorative in my use of "rushing")
will not actually help the current situation.
 
Cheers,
Adrian
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry
Leiba
Sent: 25 October 2012 14:20
To: Noel Chiappa
Cc: [email-masked]
Subject: Re: don't overthink, was Just so I'm clear

Alas, that's not how we do things.  We have a process, and we need to follow it.
Anything else does NOT have legitimacy.
 
I suggest that

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

---

From: SM <[email-masked]>
Date: Thu, 25 Oct 2012 08:22:03 -0700

Hi Noel,
>any/all policy/procedures, right?

It's going to be controversial.

>decide/declare that positions are vacant due to the withdrawal of the holder.

See http://www.ietf.org/mail-archive/web/ietf/current/msg75474.html

>_any other policy/procedure set into place by the IETF in plenary mode_.

Julian Reschke mentioned the following [1] on an unrelated thread:

   "The IETF is open to anyone, works async on mailing lists, and doesn't
    require any membership fees. I don't think there's any standards body
    that is *more* open to individuals."

I would add the word "fair" to the above.

>focus on the most economical way to achieve that purely bureacratic action.

Yes.  The problem with fairness is that it can be an overhead.  Its 
advantage is a sense of legitimacy which is more than a piece of 
paper, electronic or otherwise, can do.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg75340.html

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Oct 2012 18:57:00 +0200

On Oct 25, 2012, at 16:37, "Adrian Farrel" <[email-masked]> wrote:

> retro-active

I don't get how that is relevant.
This is for the case the seat is still vacant when the new process comes into force.

I'm still amazed at the number of messages the resolution of this issue has generated.
There is complete consensus on the needed outcome, so finding a procedure should mostly be a matter of consulting counsel.
(All that while showing our respect for the individual caught up in this situation, I should add.  
Not one of mailing list discussions' strongest points.  And that's why I'm going to shut up again, now.)

Grüße, Carsten

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Oct 2012 11:52:46 -0700

> This is for the case the seat is still vacant when the new process comes into force.

When Marshall was appointed the rules we have now were in place. To
change the rules now, and then apply them to this situation is by
definition retroactive.

Doug

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Oct 2012 21:05:02 +0200

> change the rules now, and then apply them to this situation is by

There is some confusion in this argument:
We are not doing penal code here, where such a definition would indeed apply.
  
We are trying to keep the IAOC functioning.

If the IAOC is still impaired at the time the new process comes into force, 
there is nothing retroactive about acting on the situation then and there.

Grüße, Carsten

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Oct 2012 12:13:28 -0700

> there is nothing retroactive about acting on the situation then and there.

First, I disagree with your belief that what you propose would not be
retroactive. Second, it's worth pointing out that if the IAOC put an
equal amount of effort into the recall procedure, the problem would be
just as solved, without danger of repercussion.

Doug

---

From: Melinda Shore <[email-masked]>
Date: Thu, 25 Oct 2012 11:21:18 -0800

> just as solved, without danger of repercussion.

In the interest of progress, what do you think *should* be done?
Yesterday you said that you were not in agreement with declaring
the position vacant in this manner.  Is it that you think that
Marshall should not be removed at all, that you think Marshall
should not be considered as having resigned, that you think ... ?
How do you think this should be resolved?

Melinda

---

From: Doug Barton <[email-masked]>
Date: Thu, 25 Oct 2012 12:28:55 -0700

> How do you think this should be resolved?

I've said it many times already. Start the recall.

---

From: Michael StJohns <[email-masked]>
Date: Thu, 25 Oct 2012 16:49:15 -0400

>any/all policy/procedures, right?

Actually, that's my point here.

Once upon a time, we did everything by group hum.  Then we became a standards body with formal procedures and gave up the power to change any/all policy/procedures by just wishing they were changed.

As I see it, with respect to this "problem" -

The IAOC has no power to declare the position vacant.  They know this, and that's why they sent a note to the list asking for "permission".

But - the IETF may do one of two things:
   1) It may change the procedure/policy by using the existing defined procedures and policies and THEN follow the new procedure policy. 
or
   2) It may initiate the recall procedures.

AFAIK the IETF "plenary" does not have the powers you suggest it has.

Mike

---

From: Sam Hartman <[email-masked]>
Date: Thu, 25 Oct 2012 18:51:39 -0400

>>>>> "Michael" == Michael StJohns <[email-masked]> writes:

    Michael> At 08:53 AM 10/25/2012, Noel Chiappa wrote:
    >> We're all agreed that the IETF in plenary mode (i.e. all of us)
    >> can change any/all policy/procedures, right?

    Michael> Actually, that's my point here.

    Michael> Once upon a time, we did everything by group hum.  Then we
    Michael> became a standards body with formal procedures and gave up
    Michael> the power to change any/all policy/procedures by just
    Michael> wishing they were changed.

I started to say yes to the above statement but then ran across so many
problems that I'm going to say...
No, it's quite obvious to me the IETf in plenary mode doesn't have this
power.
Foundational procedures are created by approving a BCP.
The IETf in plenary mode can reach consensus to do that but:

1) publication of an RFC on the IETF stream requires the consensus of
the IESG. Presumably if there's a strong consensus in the IETF and a
lack of consensus on the IESG, we're set up for a constitutional crisis
or a run of the recall procedure real quick.

2) IETF process documents require approval by the ISOC BOT.

3) There is a variance procedure. I've always been puzzled by it because
it seems to require exactly the same things as approving a new procedure
plus extra work.

4) I do not believe that the IETF in plenary has the ability  to choose
to ignore its procedures or to take an action that rightfully ought to
require a BCP without such a BCP.

5) We as individuals can always form IETF' and start going there instead
of IETF if we don't like the IETF. There's a bit of a high bar in
convincing ISOC,  sponsors, the ITU and others that they too want to
attend IETF' meetings and get rid of this IETF thing.

---

From: SM <[email-masked]>
Date: Fri, 26 Oct 2012 02:35:30 -0700

>2) IETF process documents require approval by the ISOC BOT.

Not really.  The ISOC Board of Trustees is not in the loop when it 
comes to IETF document approval.

>it seems to require exactly the same things as approving a new procedure

It's generally a bad idea to make rules to address a specific case or 
to craft rules to favor or take action against one party.  A variance 
procedure is useful for unforeseen procedural issues.  Without it a 
system ends up being rigid.  The problem with variance is generally 
the "collateral and precedential effects of granting a variance".

At 00:11 26-10-2012, Brian E Carpenter wrote:
>What he said. Common sense should prevail. We can fix *this* tiny gap in
>our procedures in due course, but we will need to apply common sense again
>the next time we find a tiny gap.

Common sense is rarely used as a justification as there isn't IETF 
Consensus on the meaning of "common sense".  I edited the text posted 
by the IAOC Chair [1]:

   The IAOC believes that it is reasonable to fill his position for the
   remainder of his term as the IAOC has been unable to communicate with him
   since 1 August 2012.

It's going to be difficult to argue that it is not reasonable to fill 
the position.  Now, if someone argues that it is unreasonable, you 
can try to show that the person is being unreasonable or you can 
accept the opinion.  The latter is somewhat related to the notion of 
consensus.  The former raises questions about the presumption of good faith.

At 18:21 25-10-2012, Theodore Ts'o wrote:
>Still, I'm curious why the absence of one person is so great that
>people want to make emergency rule changes and why people are treating
>this as some kind of constitutional crisis.  Is there part of the
>story which I am missing?

It's an awkward situation.  "The IAOC proposed this approach because 
we think it would cause the least amount of embarrassment" [2].

At 13:44 25-10-2012, Doug Barton wrote:
>Without any personal knowledge of his circumstances, I'm not prepared to
>judge him.

Yes.

At 11:40 25-10-2012, Doug Barton wrote:
>are saying is that we don't agree. Given that the only choices are
>"vacant, or recall;" and given that the vacant state of the seat isn't
>100% clear, at this time recall is the only option.

One generally takes a three-way hum [3].

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf-announce/current/msg10812.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg75414.html
3. http://www.ietf.org/mail-archive/web/ietf/current/msg75523.html

---

From: Sam Hartman <[email-masked]>
Date: Fri, 26 Oct 2012 07:20:46 -0400

>>>>> "SM" == SM  <[email-masked]> writes:

So, I'm puzzled by this.  my claim was that ISOC needed to approve
process related BCPs.  If you take a look at RFC 2031, it supports that
claim.  However, I'd kind of expect the other half of this to be in RFC
2026.  I certainly recall us sending things like BCP 101 before the ISOC
BOT. I also think we sent a couple of other documents there because they
were process documents.
However this is clearly more complex than I thought it was.

Scott, or anyone else with more history, can you tell us a story about
how this works?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Oct 2012 13:25:04 +0100

Hi Sam,

> Scott, or anyone else with more history, can you tell us a story about

My recollection from a few years ago is that we put various new process BCPs
in front of the ISOC Board and they minuted that they took note of them.
They were specifically not asked to approve them.

It's quite possible that this has been overlooked in some cases. Somebody
would have to grep the ISOC Board minutes to be sure.

   Brian

---

From: Scott O Bradner <[email-masked]>
Date: Sun, 28 Oct 2012 07:35:25 -0400

Sam -
	The ISOC BoT has generally (with some slip-ups) accepted IETF process documents as 
describing the IETF process - this has been seen as a good idea for the insurance coverage

there is no requirement in the IETF process that such RFCs be approved by the ISOC board 
nor that they are accepted as describing IETF process before the RFCs become active 

see, for example, Resolution 2006-36 
http://www.internetsociety.org/who-we-are/board-trustees/list-resolutions

Scott

---

From: Ted Hardie <[email-masked]>
Date: Sun, 28 Oct 2012 10:24:39 -0700

> http://www.internetsociety.org/who-we-are/board-trustees/list-resolutions

The other piece to this is in RFC 2026, in the section on appeals:

   Further recourse is available only in cases in which the procedures
   themselves (i.e., the procedures described in this document) are
   claimed to be inadequate or insufficient to the protection of the
   rights of all parties in a fair and open Internet Standards Process.
   Claims on this basis may be made to the Internet Society Board of
   Trustees.

By sending process documents to the ISOC Board on adoption, the IETF
avoids the late surprise possibility that they will later be found to
be "inadequate or insufficient".  That doesn't eliminate the right of
appeal (someone filing one may raise and issue that the Board didn't
consider), but it does mean that there is some context when appeals
occur.

It may not be strictly required, in other words, but it is a good idea.

My two cents,

Ted Hardie