Re: Proposed Revisions to IETF Trust Administrative Procedures

Ted Hardie <> Fri, 11 April 2008 05:27 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 395293A6E01; Thu, 10 Apr 2008 22:27:12 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E5293A6DE6; Thu, 10 Apr 2008 22:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kcFgWFE4cQwL; Thu, 10 Apr 2008 22:27:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 02FA93A6DC0; Thu, 10 Apr 2008 22:27:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1207891651; x=1239427651; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-originalarrivaltime: x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20<p06240600c424a4322622 @[]>|In-Reply-To:=20<47FEBD19.2030206@isoc.or g>|References:=20<20080407194507.44B6028C21E@core3.amsl.c om>=0D=0A=20<CAB795A3F7B5B1851E831FBB@beethoven.local>=0D =0A=20<0BDFFF51DC89434FA33F8B37FCE363D511F94E2B@zcarhxm2.>=0D=0A=20<E974AC59312981BA5F1A1364@p3.JCK .COM>=09<>=0D=0A=20<33EDFDB1A6B B5C5B68362C2C@p3.JCK.COM>=0D=0A=20<405E5ABA-C7C2-4A2A-884>=0D=0A=20<BE553BCE544B8A 70231137C9@p3.JCK.COM>=0D=0A=20<0BDFFF51DC89434FA33F8B37F>=0D=0A=20<3835AF BD96412EAF1839026B@p3.JCK.COM>=09<47FD4211.3040902@gmail. com>=0D=0A=20<>|Date:=20Thu,=201 0=20Apr=202008=2022:27:22=20-0700|To:=20Ray=20Pelletier =20<>,=0D=0A=20=20=20=20=20=20=20=20Br ian=20E=20Carpenter=0D=0A=09<> ,=20<>|From:=20Ted=20Hardie=20<hardie@qualco>|Subject:=20Re:=20Proposed=20Revisions=20to=20IETF =20Trust=20Administrative=20Procedures|CC:=20John=20C=20K lensin=20<>,=0D=0A=20=20=20=20=20=20=20 =20Leslie=20Daigle=0D=0A=09<>,=0D =0A=20=20=20=20=20=20=20=20IETF=20Discussion=20<ietf@ietf .org>,=0D=0A=20=20=20=20=20=20=20=20Harald=20Alvestrand =0D=0A=09<>|Content-Type:=20text/plai n=3B=20charset=3D"us-ascii"|X-OriginalArrivalTime:=2011 =20Apr=202008=2005:27:26.0636=20(UTC)=20FILETIME=3D[BA7E3 EC0:01C89B94]|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5100,188 ,5271"=3B=20a=3D"2364128"; bh=L3u3zRpYprQi+GdULLwYd91VgU+IdsRWR+Y443JqOhc=; b=pwkzbIysoNl15teQ0/1uJMYAcSPyQGBIzIEPZPvmXiBhr+gTP97DMhUC B3QvrHxJfAzj95DL2+P0kMbxUrWZ2hD/jucdmb6XPZ/Gwvz1B2yL3N9Gm mC44XLVeze1Qso9fSgCJA215hCnWThEy6IQpOIQM3eR1mkOnA4Eqw4qzu U=;
X-IronPort-AV: E=McAfee;i="5100,188,5271"; a="2364128"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2008 22:27:30 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m3B5RUW8020312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Apr 2008 22:27:30 -0700
Received: from ( []) by (8.14.2/8.14.2/1.0) with ESMTP id m3B5RQ9b021330; Thu, 10 Apr 2008 22:27:27 -0700
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Apr 2008 22:27:26 -0700
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Thu, 10 Apr 2008 22:27:25 -0700
MIME-Version: 1.0
Message-ID: <p06240600c424a4322622@[]>
In-Reply-To: <>
References: <> <CAB795A3F7B5B1851E831FBB@beethoven.local> <> <E974AC59312981BA5F1A1364@p3.JCK.COM> <> <33EDFDB1A6BB5C5B68362C2C@p3.JCK.COM> <> <BE553BCE544B8A70231137C9@p3.JCK.COM> <> <3835AFBD96412EAF1839026B@p3.JCK.COM> <> <>
Date: Thu, 10 Apr 2008 22:27:22 -0700
To: Ray Pelletier <>, Brian E Carpenter <>, <>
From: Ted Hardie <>
Subject: Re: Proposed Revisions to IETF Trust Administrative Procedures
X-OriginalArrivalTime: 11 Apr 2008 05:27:26.0636 (UTC) FILETIME=[BA7E3EC0:01C89B94]
Cc: John C Klensin <>, Leslie Daigle <>, IETF Discussion <>, Harald Alvestrand <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

I have resisted contributing to this thread because so many of the salient
points had already been made.  But permit me to make a small observation.

This proposal has a general thrust that seems to say "This position is important, and
we don't want to pile too much power in one pair of hands, so we can't let the
following folks take the position, and we need explicit ways of removing someone from
the position."  It also has a section (d), which downplays that reading by saying:

> The Chair shall convene and preside over meetings of the Trustees but shall have no other powers or authority beyond his or her powers as a Trustee.  If the Trust Chair is not available, then any other Trustee may convene or preside over meetings of the Trustees in the  absence of the Trust Chair.

When Brian tried to create "Vice Chairs" for the IESG, the IESG of the time
was very concerned with both the optics inside the IETF, the optics outside
the IETF, and the chance that Vice Chairs would eventually come to believe that
they had a role  beyond chivvying folks to do get their positions
in on time.  After much discussion, including silly suggestions by me,
"Whips" got picked as the title instead.  That worked, and the people doing
the job helped a lot in taking up tasks that Brian did not have time for.

A "Whip" is not what you're looking for here, but it seems clear to me that
the terminology of "Chair" is going to set up the same kind of expectations
that have caused problems before.  This person *will*, for example, get called
for quotes by press looking at IPR issues in the IETF.  They can push those off,
but believe me that there is a target painted on the back of the stuckee
with this choice of phrase.

Call this role a "meeting convener" or "show runner" or "den mother" or
something else less likely to cause confusion and attract trouble.  That will help,
at least in my opinion.  Names matter, and the one you've chosen implies powers
that all the sub-clauses in the document can't truly take away.

Thanks for listening,

At 6:21 PM -0700 4/10/08, Ray Pelletier wrote:
>The Trustees have considered the comments from the list and propose the following amended revisions to the Trust Administrative Procedures.  The Trustees propose to take action at its April 17th meeting and will consider all comments received by that date.
>2. The Trustees shall select one Trustee to serve as the Chair of the Trust. 
>a. The following Trustees are not eligible to serve as IETF Chair:
>    1. ISOC President
>    2. IAB Chair
>    3. IETF Chair
>    4. ISOC IAOC Appointee
>    5. IAD
>b. The term of the Trust Chair shall be one year from the time of selection or the remaining time of his or her tenure as a Trustee, whichever is less.  An individual may serve any number of terms as Chair, if selected by the Trustees.
>c. The Chair serves at the pleasure of the Trustees and may be removed from that position at any time by a vote of 2/3 of the voting Trustees, not counting the Trust Chair.
>d. The Chair shall convene and preside over meetings of the Trustees but shall have no other powers or authority beyond his or her powers as a Trustee.  If the Trust Chair is not available, then any other Trustee may convene or preside over meetings of the Trustees in the  absence of the Trust Chair.
>4. The Trust Agreement defines the quorum and voting rules for a meeting. Motions passed by electronic means between meetings shall be confirmed by a vote at the next possible meeting.
>12. The Trustees are the current members of the IAOC. When a member leaves the IAOC for whatever reason, he or she ceases to be a Trustee. When a new member joins the IAOC, he or she becomes a Trustee upon his or her agreement in writing to fulfill the duties of a Trustee, as specified in the Trust Agreement.
>a. If at any time the IAOC ceases to exist, or there are fewer than three Trustees, then the IESG, or its successor, shall appoint Trustees in accordance with Article VI of the Trust Agreement.
>Brian E Carpenter wrote:
>>On 2008-04-10 07:04, John C Klensin wrote:
>>>--On Wednesday, 09 April, 2008 13:50 -0400 Ed Juskevicius
>>><><> wrote:
>>>>John, you wrote:
>>>>>Then recommend to the community that the Trust Agreement be
>>>>The Trustees are not talking about changing the terms of the
>>>>Trust Agreement, so this should not be necessary.
>>>Good.  But I was just trying to suggest, following what I
>>>thought I saw in Marshall's note, that, if the Trust Agreement
>>>is defective, one could try to change it.  The other option is
>>>to conform to it.  Ignoring it and adopting procedures or
>>>polices inconsistent with it --even if one believes those
>>>policies will never be triggered-- is a non-starter.
>>>>>I am worried about the IAOC and/or Trustees adopting
>>>>>procedures that are inconsistent with the Trust Agreement.
>>>>Me too! It is not the intention of the Trustees to adopt
>>>>procedures that are inconsistent with the Trust Agreement. 
>>>>>if anything is going to be said, it needs to be consistent
>>>>>with the Trust Agreement _and_ reflect the desires and intent
>>>>>of the community.
>>>>I agree.
>>>I think we are in synch.
>>I agree with the above, and I assure everybody that the intent
>>was always exactly that. There's definitely an error in the way
>>the current procedures were drafted; it was my error, and I have
>>evry confidence that the current Trustees will fix it.
>>    Brian
>>IETF mailing list
>Content-Type: text/plain; name="ATT00001.txt"
>Content-Description: ATT00001.txt
>Content-Disposition: attachment; filename="ATT00001.txt"; size=191;
>	creation-date="Thu, 10 Apr 2008 19:01:43 GMT";
>	modification-date="Thu, 10 Apr 2008 19:01:43 GMT"
>Attachment converted: Macintosh HD:ATT00001 1073.txt (TEXT/ttxt) (0074B34C)

IETF mailing list