Re: Proposed Revisions to IETF Trust Administrative Procedures

John C Klensin <john-ietf@jck.com> Fri, 04 April 2008 05:22 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AEAA3A6916; Thu, 3 Apr 2008 22:22:02 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452283A69CB for <ietf@core3.amsl.com>; Thu, 3 Apr 2008 22:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.703, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1iWjnPKFNaH for <ietf@core3.amsl.com>; Thu, 3 Apr 2008 22:21:58 -0700 (PDT)
Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id DCDD73A696D for <ietf@ietf.org>; Thu, 3 Apr 2008 22:21:57 -0700 (PDT)
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1JheND-0004iQ-4J; Fri, 04 Apr 2008 01:22:00 -0400
Date: Fri, 04 Apr 2008 01:21:57 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Proposed Revisions to IETF Trust Administrative Procedures
Message-ID: <ECC7E471BB6B63FEAEA5AB1D@p3.JCK.COM>
In-Reply-To: <47F55CB3.80403@gmail.com>
References: <47F52D51.4030501@isoc.org> <05216A653F92E3BAE8A4A244@p3.JCK.COM> <47F55CB3.80403@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Disposition: inline
Cc: IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


--On Friday, 04 April, 2008 11:39 +1300 Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:

> John,
> 
> On 2008-04-04 09:54, John C Klensin wrote:
>> Ray,
>> 
>> Some observations...
>> 
>> (1) If someone doesn't become a Trustee until her or she is
>> willing to sign something, one either needs to have explicit
>> provisions for what happens if someone declines to sign or
>> willingness to sign has to be an explicit condition for
>> membership in the IAOC.  Since several of the IAOC members are
>> ex-officio, I don't really see how to do the latter, but it is
>> probably possible.
> 
> This change to the admin procedures is a no-op, since it
> merely repeats what is said in 6.1(a) of the Trust Agreement.
> So it's clear enough: someone who hasn't signed is *not* a
> Trustee. If an IAOC member fails to sign and is not subject to
> IETF recall, that sounds like an HR issue to me. I don't see
> what we can do in our texts, so I support the proposed change
> (even though it's a no-op).

Brian, the recall process, even if we figured out how to use it
in practice rather than in theory, takes months.  So, if we do
things this way, we need to change the selection requirements
for an IAOC member (and that includes the IETF Chair and IAB
Chair) to include a formal commitment to willingness to sign.

That is why this proposed change, even though I understand why
you call it a no-op, may be wrong.  Wouldn't it be better to
figure out a way to get someone to sign as part of the relevant
selection process, effective when they are seated as IAOC
members, so that we don't have a potential race condition or
problem after they are seated?   See the difference?


>> (2) Because some members of the IAOC are appointed by (or
>> ex-officio from) other bodies, I would prefer that, if there
>> is going to be a separate Trust Chair, that person be
>> required to be an IETF appointee and subject to recall.  No
>> matter how many "the Chair is nothing special" rules one has,
>> we all know from experience that long-term (as distinct from
>> rotating) chairs of long-lived bodies tend to be treated,
>> externally at least, as spokespeople, etc.
> 
> I agree that the two staff positions in the IAOC (IAD and ISOC
> President/CEO) should not be eligible as Trust chair, since
> there is no recall path.  (Obviously I don't suggest that
> either of them is otherwise unsuitable ;-)

Well, the IAD _is_ unsuitable, not because of any issues with
the incumbent, but because the optics of having the IAD, who is
selected and supervised by an IAOC subcommittee, chairing the
Trust (or the IAOC for that matter) are just not attractive.

But I also said "IETF appointee", presumably including the IETF
Chair, the IAB Chair, and those appointed by the IAB, IESG, and
Nomcom.  You seized on the "subject to recall" part, which was
less important, especially how frequently we use the recall
process to correct problems.  Perhaps I should have said "IETF
appointee and therefore subject to the IETF's current version of
public flogging" instead.   If we are going to preserve the
IETF-ISOC relationship that was so carefully negotiated in RFC
4071/BCP 101, then I don't think that an ISOC-appointed member
of the IAOC should be permitted to be IETF Trust Chair.

>> (3) I don't recall seeing it before, which may be my fault,
>> but the provision that, if the IAOC is dissolved, the Trustees
>> become permanent appointments and get to determine the Trust's
>> fate is very unattractive.  Probably the Trust and/or IAOC
>> procedures or charter should be modified so that, in the event
>> of the demise of the IAOC, the Trust falls firmly under direct
>> IETF control (unless the IETF itself ceases to exist).   There
>> might be other ways to do it, but perhaps the termination of
>> the IAOC without other provisions should immediately add the
>> entire IAB and/or IESG (or whichever one survives),
>> ex-officio to the voting roster of Trustees for the duration.
> 
> That really fills a small gap in the Trust Agreement (which
> talks about what happens if the IETF or IESG ceases to exist
> but not if the IAOC ceases to exist). I think you're correct
> that it could be improved, but can we separate that from the
> current proposed changes?

Sure.  Especially if someone explains why the other changes have
to be done on a hurry-up basis.

    john

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf