--On Tuesday, June 23, 2009 01:32 -0400 Marshall Eubanks
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
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,
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.
Ietf mailing list