Appeal/Request for Review (was: Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP))

John C Klensin <> Sat, 18 July 2009 19:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 753923A69FD; Sat, 18 Jul 2009 12:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U-uMTMW7PCeu; Sat, 18 Jul 2009 12:41:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 866023A67A1; Sat, 18 Jul 2009 12:41:40 -0700 (PDT)
Received: from [] (helo=localhost) by with esmtp (Exim 4.34) id 1MSFk9-0001jm-6z; Sat, 18 Jul 2009 15:38:49 -0400
Date: Sat, 18 Jul 2009 15:38:47 -0400
From: John C Klensin <>
To: Marshall Eubanks <>, Bob Hinden <>
Subject: Appeal/Request for Review (was: Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP))
Message-ID: <CEEDB373107D5559B510618C@PST.JCK.COM>
In-Reply-To: <>
References: <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Trustees <>,, IAB IAB <>, ietf list <>, IESG <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 18 Jul 2009 19:41:44 -0000

--On Saturday, July 18, 2009 12:55 -0400 Marshall Eubanks
<> wrote:

> Hello;
> We (the Trustees) have received feedback on the proposed
> changes to the Trust Legal Provisions (TLP) and have agreed to
> take the following actions. Since the original call went out
> on the 23rd of June, the comment period is extended to the
> 23rd of July.


While I believe these changes are all improvements, I also
recall several additional sets of comments on the IETF mailing
list, including those that addressed the issues of:

	(a) The relationship between the multiple-track
	definitions in RFC 4844 and, in particular, what it
	describes as the "IETF Track" versus other tracks (IAB,
	IRTF, Independent Submission) as compared to the
	apparent assumption of the TLP that all I-Ds and RFCs
	are IETF documents.
	(b) The provisions in the TLP that all IPR policies are
	to be developed according to the Trustee's
	interpretation of IETF Consensus.   RFC 4844 and
	long-term practices assume that there are broader, or at
	least different, communities involved in decisions about
	policies, including IPR policies, involving
	non-IETF-track documents.
	(c) Members of the community also questioned the
	process that the Trustees used to develop these policies
	and whether their content and style exceeded the
	authority of the Trustees under BCP 101 and the social
	contract between the Trustees and the community.

Should we assume that these issues (and others that I recall
less clearly) were addressed by the Trustees and rejected?   If
so, why has not the reasoning been supplied as required by BCP
101?  Or did they fall through the cracks or were dismissed out
of hand, without consideration?  

I note that

(1) the standard practice in the community, as exemplified by
IESG behavior under the sections of RFC 2026 in which the
lengths of Last Calls are specified, are that, if a document is
changed in a significant way, a new Last Call is issued,
normally with the same duration as the original.  The
"extension" to July 23 given new text provisions that are
announced only on 18 July amounts to a five day comment period
on those changed provisions in context with the rest of the
document.  I suggest that a five day review period not only does
not conform to the intent of provisions for comment and review
by the community but that it borders sufficiently on abusive for
me to request a review of the "operational procedures" of the
Trustees, both generally and as they apply to this action.

(2) the Trustees have published no minutes this calendar year,
or indeed since September 2008, so the answers to these
questions cannot be deduced from those minutes.  

(3) failure to publish minutes (only one set of minutes has been
published in the last 12 months), or otherwise keep the
community informed in a timely way about decisions and actions
of the Trustees violates the accountability requirements
specified in the first paragraph of Section 3 of RFC 4071, the
documentation requirements (including the reasons for decisions)
in the fourth paragraph of that section, the requirement for
transparency in the fifth bullet of Section 3.2, the "direct
accountability" provisions of Section 3.3,  and the general tone
and agreements that comprised the community discussions leading
up to the adoption of RFC 4071 as BCP 101.   

(4) the IPR discussion in Section 3 of RFC 4071 authorizes the
IASA to "manage" only those IPR rights that "belong to the IETF".

(5) nothing in RFC 4371 modifies the provisions discussed above.
The Trustees have the same responsibilities of openness,
transparency, accountability, and relationship to the community
that the IAOC does and members of the IAOC, whether acting as
Trustees or as IAOC members, have those same responsibilities.

(6) the Trustees have published what appears to be, in the
language of BCP 101, an "operational procedures" document in the
form of the "Administrative procedures of the IETF Trust", dated
(  Those
those procedures appear to contain no provisions at all for
consultation with the community or documentation consistent with
the openness, transparency, and accountability provisions of BCP

Consequently, by this message to you and copy of this note to
the IAOC Chair, and under the provisions of Section 3.5 of RFC
4071, I formally request that the Trustees review their actions,
that the IAOC review the actions of the Trustees as part of the
IASA process, and that the following actions be taken:

(i) The Trustees take no further action on any non-emergency
matter until all minutes are up to date and, either as part of
those minutes or otherwise, the Trustees have, as required by
BCP 101, explained to the community the reasoning behind past
decisions, not just announced those decisions.  I believe that
the community would agree that "no more than one meeting behind"
is a sufficient approximation to "up to date" for this purpose
while one set of minutes published with the last twelve months
is clearly not; 

(ii) For those issues for which the Trustees can identify an
emergency requiring immediate action, the provisions of (i) are
waived.  However, identification of an emergency should require
that the emergency and the reasoning supporting that declaration
be identified to the community in a way that can be reviewed
(even if only after the fact and for future adjustment of
procedures).  The provisions identified above with regard to
openness, transparency, and accountability with regard to the
emergency are not waived: the Trustees are still required to
report on decisions and the reasoning for those decisions in a
manner that is sufficiently timely to give the community
opportunity for input unless they can demonstrate to the
satisfaction of the community (also if necessary after the fact)
that harm would occur from those open and transparent practices.

(iii) The Trustees should never issue a call for comment on any
issue lasting less than four weeks unless they can justify the
issue as an emergency as described above.   Even under emergency
circumstances, if there is time for any comment period at all,
there is time to explain to the community why that should be
shorter than four weeks.  To prevent misunderstanding, this
request is for an explanation as provided for in BCP 101, not an
announcement of a decision by the Trustees that a shorter period
is appropriate.

(iv) The Trustees, as a priority matter, explain to the
community how policies that assume that all I-Ds and RFCs are
"IETF documents" are harmonious, or can be harmonized, with the
multi-track model of RFC 4844 and with traditions that go back
to RFC 2026 and much earlier for treating documents that are not
the result of IETF processes (and that may not have been
discussed and reviewed in the IETF).  If proper consideration of
such documents requires revising the Trust Agreement itself, the
Trustees should expeditiously undertake that revision so as to
clarify the status of those documents.

(v)  With regard to the TLP in particular, the Trustees will
provide the community with a summary and review of comments made
on the June 23rd version of that document, their decisions about
each  comment, and the reasoning for those decisions.  No
comment period on any revised draft will be initiated until
after the community has that documentation in hand.  This is a
requirement that is clearly suggested by BCP 101.  While this
level of detail should not be necessary, the previous behavior
of the Trustees, as described above, indicates that it is a
necessary and appropriate remedy.

(vi) The Trustees treat the authorities granted to themselves by
the "Administrative Procedures" document as invalid and without
force until that document is updated to contain specific
provisions for openness, transparency, and accountability,
including the provisions for review outlined above, and the
rough consensus approval of the community is obtained for that

(v) The Trustees discuss with the IAD (and with themselves as
the IAOC) the question of whether production of timely and
comprehensive minutes requires professional staffing and, if so,
how such staffing can be obtained and covered out of the
relevant budgets.

Finally, I wish to note that while BCP 101 gives the Trustees
and IAOC 90 days to respond to this request for review and broad
discretion about how they respond, taking action on the TLP that
would either be irreversible or that would confuse other
procedures while the review request is under consideration would
constitute grounds for immediate appeal as provided for in
Section 3.5 of RFC 4071 and in RFC 2026.

thank you,
    John Klensin