Re: [IAB] Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[John C Klensin <[e-mail]>]

--On Tuesday, June 23, 2009 01:32 -0400 Marshall Eubanks
<[e-mail]> wrote:

> The IETF Trustees invite your comments on the proposed
> revisions to the "Legal Provisions Relating to IETF Documents"
> (TLP) policy.  The proposed revisions are in rtf, pdf and doc
> formats and located at:
> http://trustee.ietf.org/policyandprocedures.html  under Draft
> Policies and Procedures for IETF Documents.
> 
> This is a summary of the proposed revisions:

First, something that is not on your list but that is
problematic, both from the standpoint of the text and from that
of what it might tell us about other changes noted below.

The statement in 2.b, in conjunction with a July 2009 Effective
Date (see the top of the document), leaves documents published
between the presumptive Effective Date of the procedures in
effect today and that date in a strange sort of never-never
land, since 2.b doesn't mention 5378.

I can only infer from this that the Trustees did not do a
careful review of the proposed new procedures in toto.  That is
not a good sign, especially if you are simultaneously asking for
a review period that is consistent only with documents that have
been thoroughly vetted (see below).

> 2.e -- the review period for TLP changes has been changed from
> 30 to 14 days, which is consistent with the last-call period
> for other IETF documents

Actually, no, it is not.  The IETF rule is 14 days for working
group documents... working groups that are open, maintain open
mailing lists and real-time archives for discussion, and where
the documents are I-Ds that are posted, generally available, and
that have achieved WG consensus.  The "WG Consensus" part is
particularly important given the example of Section 2.b of this
draft (discussed above) because such consensus implies that a
lot of people have examined the document carefully, typically
through multiple iterations (sometimes the process fails, but
that is clearly the expectation).   Any other flavor of IETF
document, including individual submissions that are posted as
I-Ds and discussed extensively on public (but non-WG) mailing
lists, requires a four-week review period.  That is a four-week
period after the IESG decides to initiate a Last Call.   I
cannot remember such a Last Call being initiated, ever,
immediately after a -00 I-D is posted and I believe current IESG
de facto procedures would make that impossible.  Realistically,
the shortest possible review period for a non-WG document,
measured from the first draft the community sees of the
document, is about six weeks and I suspect we haven't see that
in years and years.  In practice, it is probably even longer for
WG documents.

So, as 2.e reads in the proposed version, the Trustees will post
a planned TLP change and immediately request comment on it.
The first time the community will see it is when you make that
request.  BCP 101 notwithstanding, the Trustees apparently feel
no obligation to give the community advance warning that you are
considering TLP changes and what is in them and, unlike WG
mailing lists, interested members of the community cannot
subscribe to receive the Trustee mailing list nor access its
archives on a schedule contemporary with actual discussion.

Perhaps 14 days is reasonable. I think it is not for several
reasons, not least of which is that new legal provisions may
require that some members of the community consult with their
own organizational legal counsel before determining how and
whether to comment.  But it certainly cannot be justified on the
basis of alignment with IETF Last Call periods.

> 2.f -- this new language describes the conditions under which
> the IETF Trust will assume licensing and copyright
> responsibility for IAB, IRTF and Independent Stream
> submissions, should the managers of those streams request that
> it do so.

2.f(iii) is inconsistent with RFC 4844, the draft RFC Editor
Model document, and, I believe, with the intent of the
authorizing/ founding documents for the IETF Trust itself.
While the Trustees should clearly do what the IETF tells you to
do (as long as it is logically and legally plausible) wrt IETF
stream documents, your responsibilities are to the broader
community whose needs may, in principle, be different from those
of the IETF.  The statement here effectively requires that the
Trustees must follow the wishes of the IETF with regard to all
streams.  That is not acceptable and interacts in an interesting
way with a provision of the Trust Agreement (see below).

I suggested some alternative language to the IAB when we saw a
preview of this proposal.  I will attempt to find that and post
it to the IETF list.


In Section 3.c, there is a possible issue that I had not noticed
until I went back and reread the Trust Agreement in conjunction
with the provisions of this proposal.   That agreement, in its
Section 9.5, imposes some very specific requirements on any
licenses granted by the Trust for "IPR other than rights in IETF
standards-related documents".  RFCs from non-IETF streams are
clearly not "IETF standards-related documents" so Section 3.c of
this proposal, by not containing those provisions, appears to
violate the Trust Agreement.

Do the Trustees intend to fix this, or is it your intent to
modify the Trust Agreement to conform with this draft TLP (or
the present one, for that matter) and to do so before July 1,
2010?


>...
> 6.b -- a new sentence has been added to the legend that must
> be placed on all IETF Documents, pointing out the BSD License
> requirements described in 4.e above and emphasizing that code
> in IETF Documents comes without any warranty, as described in
> the BSD License.

Given the principle that we incorporate as much text by
reference as possible rather than adding boilerplate to
documents, what makes the code components so special as to
justify a violation of that principle?  If this additional
statement is needed, it should be incorporated into one of the
relevant BCPs and then picked up as part of those references.
Adding that sentence is boilerplate creep and clearly
inconsistent with the intent of the IPR WG output.

>...
 
> I expect the Trustees will decide on whether to adopt this
> revision shortly after July 20, 2009.

For the reasons above, I believe this document needs at least
one more pass, and review by the community of the results of
that pass, before the Trustees should take final action.

regards,
   john