Subject: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

From: Marshall Eubanks <[email-masked]>
Date: Tue, 23 Jun 2009 01:32:05 -0400

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:

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

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.

4.a -- the URL for the list of Code Components has been updated

4.c -- clarifies that the BSD License may not be applied to Code  
Components that come from IETF Documents as to which the Contributor  
has prohibited the making of derivative works.

4.e -- this new section clarifies the legend requirements for Code  
Components that are used in software under the BSD License. In short,  
the user must include the full BSD License text or a shorter pointer  
to it (which is set forth in Section 6.d)

6 -- the language regarding placement of legends on IETF Documents has  
been clarified.  Placement on the "first page" is no longer required,  
and authority for placement of the legends is  with the RFC Editor and  
IESG.

6.a - the words "to IETF" have been removed, to enable submission to  
IAB, IRFT and other streams.

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.

6.c -- some minor clean-up edits

6.d -- the BSD legend/pointer described in 4.e above

7.a -- correction of capitalization

Please accept this message as a formal request by the IETF Trustees  
for your review and feedback on the proposed revision to the TLP  
document. The comment period will end on July 20, 2009.

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

Regards, and thanks in advance,

Marshall Eubanks
IETF Trust Chair

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Jun 2009 03:00:28 -0400

--On Tuesday, June 23, 2009 01:32 -0400 Marshall Eubanks
<[email-masked]> 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.
> 

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

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 23 Jun 2009 09:54:08 +0200

> 14 days, which is consistent with the last-call period for other IETF

John gave several reasons why this isn't good justification, and I agree
with them.  Reading his thoughts, my opinion is that changing the time
frame from 30 to 14 days is a change in the wrong direction considering
that these documents are not developed in an open way and that the IETF
community may want to ask their lawyers to review the changes before
responding.  In my experience, getting those answers takes significantly
more time than 14 days.

...
> 6.d -- the BSD legend/pointer described in 4.e above

The text in 6.d doesn't work.  Part of the BSD license (quoted in your
document) is this paragraph:

  Redistributions in binary form must reproduce the above copyright
  notice, this list of conditions and the following disclaimer in the
  documentation and/or other materials provided with the distribution.

If you replace the BSD license with a pointer, you would violate that
part of the BSD license.

To avoid simple mistakes when changing things related to the BSD license
(which now appears to be the norm rather than the exception) I believe
it would be a good idea for the IETF Trust to talk with people and
organizations who understands open source licensing.  I'm sure the
Software Freedom Law Center could help here.

If the process to develop drafts were open and done on a mailing list, I
could have pointed out this earlier.

/Simon

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Jun 2009 09:37:40 -0400

The IESG has prepared a draft statement as a companion 
document.  Since the two are related, the IESG would like the 
community to comment on the two documents at the same time.

On behalf of the IESG,
   Russ

--- Draft IESG Statement ---

This IESG Statement obsoletes all earlier IESG Statements regarding
Copyright statements in MIB and PIB Modules.

The IESG is providing this guidance to align current practice with
RFC 5377, RFC 5378, and the resulting IETF Trust Legal Provisions (TLP)
(http://trustee.ietf.org/license-info).

IETF Contributions and IETF Documents often include code components
that are intended to be directly processed by a computer.  Examples of
such code components include ABNF definitions, XML Schemas, XML DTDs,
XML RelaxNG definitions, tables of values, MIBs, PIBs, ASN.1, and
classical programming source code.  The IETF Trust maintains a list of
code component types.  A link to this list can be found on this web
page: http://trustee.ietf.org/license-info.

In addition to the code component types listed, any text found between
the markers <CODE BEGINS> and <CODE ENDS> shall be considered a code
component.  Authors may wish to use these markers as clear delimiters
of code components.

Authors are encouraged to collect code into a separate section or
appendix.

The TLP requires copyright notice in IETF Documents, but not necessarily
in each code component within an IETF Document.  Authors may choose to
include a copyright notice as a comment when a significant amount of
code is collected together.  For example, authors may include a
copyright notice in a comment as part of an ASN.1 module or a
representation of a classical programming language file.  If IETF
Document authors choose to include a code component copyright notice
comment, they must follow the guidance in Section 6.d of the TLP.
Implementors that extract any code component from the IETF Document must
include the BSD license text as described in Section 4.e of the TLP.

At 01:32 AM 6/23/2009, Marshall Eubanks wrote:
>proposed revisions are in rtf, pdf and doc formats and located at:

---

From: John C Klensin <[email-masked]>
Date: Tue, 23 Jun 2009 11:01:18 -0400

--On Tuesday, June 23, 2009 09:54 +0200 Simon Josefsson
<[email-masked]> wrote:

>> 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
> 
> John gave several reasons why this isn't good justification,
> and I agree with them.  Reading his thoughts, my opinion is
> that changing the time frame from 30 to 14 days is a change in
> the wrong direction considering that these documents are not
> developed in an open way and that the IETF community may want
> to ask their lawyers to review the changes before responding.
> In my experience, getting those answers takes significantly
> more time than 14 days.

One additional comment on the review period and IAOC/Trustee
style of working more generally:

If one has to carefully review legal provisions, consult counsel
and others, and then comment with care and, when possible,
suggest alternate text, a review period of 14 days after one
first gets a hint that there will be document posted and seeing
the document falls into the "fire drill" category --I believe
faster than we require for any other document review in IETF or
IETF-related contexts.   While I assume that the Trustees would
be careful to avoid it if possible, holidays, vacation periods,
day-job project deadlines, and conflicts with other meetings can
easily turn 14 days into almost nothing, effectively providing
some portions of the community (not just individuals) with no
opportunity for review.

This is not a topic on which we want to have fire drills if they
can possibly be avoided.  We've repeatedly discovered that
inadequate review of IPR documents gets us documents that need
to be revised and retuned again, a process that wastes time and
creates confusion about exactly what provisions apply to which
documents.  We have even has reviews that turn out to be
inadequate when WG processes have been used with multiple I-Ds,
open community discussion of drafts, public information about
what was going into Last Call and what was not, and so on.  

However, after a few hour's thought, I believe that the basic
problem here isn't the difference between a two or four week
review window (although I still believe that two weeks is too
short).  The problem is that the IETF develops documents by
iteration before going into a Last Call/ Final Review process.
Our assumption is that Last Calls are intended as a last chance
to take another look at a document (not a first look) to catch
previously undetected and fairly serious problems... problems
that we assume won't be there because they would have been
caught in the iteration process.

The Trustees (and IAOC) have not been operating in that style.
Instead, we get documents like this one (and, as another
example, some of the RFC Editor-related materials) that are
thrown over the wall to the community with notes that
effectively say "we've finished this, you have NN days to
comment, after which we expect to make whatever changes we have
been persuaded to make and approve it".  In fairness, when the
changes have been significant enough, the community has usually
been given an opportunity to review them before final adoption,
but that is not required by these "here it comes over the wall"
statements and notes and the associated intended adoption dates.

This "throw it over the wall" model would be ok pragmatically if
the IAOC/Trustees almost always got things right.  After all,
the plan and hope for the IASA is that it would permit the IETF
community from having to deal with administrative details.  But,
using this draft with the serious problem Simon spotted and the
minor "no justification for adding boilerplate" one that I
spotted as the most recent of what have been many examples, it
appears that the IAOC/Trustees are composed of human beings with
many other things on their minds and calendars rather than of
infallible entities.  That is no surprise and not a criticism of
any of them, but it may call for some rethinking beyond
discussion of dates.

I have realized in thinking about this that my several irritated
note to or about the IAOC/Trustees in the last year or so have
been a result of this situation: if a document is going to be
thrown over the wall for this kind of final review (or, in the
more common cases, for IETF Last Call), I believe that the
community has the right to expect that it will be refined enough
that finding serious problems will be a rare event.  If
documents regularly come over the IASA/IETF wall that contain
significant problems or issues, then either the IAOC is not
doing its job or the review model is wrong.  While I apologize
for the irritated tone of some of those notes (probably
including the note I wrote several hours ago), the "not doing
the job" problem seems quite real.

I propose that, once the Trustees (or IAOC) have a preliminary
version of a document ready that they should post that document
for preliminary review, ideally as an draft-iaoc-... or
draft-ietftrust-... I-D, not a link to a web site.  That posting
should be followed by discussion between the IAOC and interested
participants in the community, iteration on that discussion as
needed, and posting of new drafts as appropriate.  Only after
that discussion and iteration process have stabilized is it
appropriate for the Trustees (or IAOC) to issue a Last Call or
anything else that bears specific intent to adopt, target
adoption dates, etc.

I would favor giving the IAOC and Trustees authority to do
something that shortcuts the above process by declaring that the
situation is an emergency but, to protect the community's
consensus processes and maintain accountability, such a
declaration should require a recorded vote with an extraordinary
majority that includes both the IESG and IAB representatives
voting for approval.

Assuming that I'm not the only one who sees the recent patterns
as problematic, are the IAOC and Trustees willing to consider
procedures equivalent to the above on an informal basis or is it
necessary to open BCP 101?

     john

---

From: "Contreras, Jorge" <[email-masked]>
Date: Tue, 23 Jun 2009 11:20:33 -0400

> But,
> infallible entities. 

John -- this is just to note that the items raised by you and Simon
aren't errors caused by hurried or sloppy work by the Trust, they are
reasonable points of disagreement over policy and interpretation.  It's
certainly legitimate for you to raise and discuss these points, but you
shouldn't assume that, just because you or Simon have a particular
interpretation, the alternate interpretation embodied in the TLP is a
careless error.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 23 Jun 2009 17:30:49 +0200

John C Klensin <[email-masked]> writes:

> as problematic

I don't think you are alone with that impression.  The process you
outline (posting preliminary versions in draft-* form) sounds great to
me.  I suggested it earlier, and the IETF Trust response was at least
not negative to the idea.  Hopefully it can be implemented.  This would
also solve the problem of recording the history of document drafts, and
making sure documents are readily available via IETF mirrors even if the
main site is down or material is removed from it, which is another
concern today.

/Simon

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 23 Jun 2009 11:39:16 -0400

> interpretation, the alternate interpretation embodied in the TLP is a

That remark suggests to me that John's proposal of iterative work is
justified.  If there are fundamental disagreements about policy and
interpretation, and not just picky details, that are coming out in the
short review period allotted, then presumably there are deep
disagreements that need to be worked out before the wider IETF can be
expected to agree to some policy.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 23 Jun 2009 19:06:44 +0300

Could you change the wording "BSD License" to "revised BSD License"
to avoid confusion with the "original BSD license"
that contained the infamous "advertising clause" ?

Is pseudocode covered by the terms of redistribution of source code in section 4 ?
The last line of the list of code component types is "classical programming code".
Does this imply a requirement that the code can be parsed by some means ?

Y(J)S

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 23 Jun 2009 12:13:14 -0400

There is an explicit list of what is automatically covered as code.
After discussion, that list does not (did not, the last time I checked) 
include pseudo-code.
Document authors are free to mark their pseudo-code using the code 
marker if they want it treated as code.

The problem, as far as I am concerned, is that pseudo-code is not 
well-defined, and therefore including it in the general list, we would 
have ambiguity as to what was or was not covered.

Yours,
Joel

Yaakov Stein wrote:
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 23 Jun 2009 18:21:32 +0200

> that contained the infamous "advertising clause" ?

I support making that change too.  (It was pointed out earlier.)

/Simon

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 23 Jun 2009 19:22:13 +0300

Joel

Yes, I referred to that list when I quoted "classical programming code".

However, as the list does not include a set of recognized programming languages,
I thought that the issue was left open.

By code marker I assume you mean <CODE BEGINS> ... <CODE ENDS>,
which is itself a kind of pseudocode.

Y(J)S

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Tuesday, June 23, 2009 19:13
To: Yaakov Stein
Cc: Marshall Eubanks; ietf list; IAB IAB; IESG; Trustees
Subject: Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

Yours,
Joel

---

From: Sam Hartman <[email-masked]>
Date: Tue, 23 Jun 2009 12:30:00 -0400

I too do not believe that reducing the review period of TLP changes is
at all reasonable.

---

From: "Contreras, Jorge" <[email-masked]>
Date: Tue, 23 Jun 2009 17:04:13 -0400

> land, since 2.b doesn't mention 5378.

The Feb. 15 version of the TLP is currently in effect.  Documents
published between Feb. 15 and the effectiveness of the revised TLP will
continue to be governed by the Feb. 15 TLP.  There should be no gap in
coverage.

> careful review of the proposed new procedures in toto.  

That is not true.

---

From: Robert Elz <[email-masked]>
Date: Wed, 24 Jun 2009 09:23:34 +0700

In other organisations, when I see (what has been called here), an
"over the wall" list of changes, I usually expect, and usually receive,
in addition to the list of changes (along with what used to be there)
all of which exists here, some kind of explanation why the changes are
being proposed.  That is, the motivation for the change.

For some of the changes here, I can guess what's up, and some of those
guesses might even be right - in others I have no idea at all what would
be motivating the proposed change.

One such is ...

  | 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 

which I can't even begin to guess at a rationale for.   What kind of
change in this area is ever going to be so urgent that even a 30 day
waiting period is a problem?   If a change were going to be made here,
I'd be expecting it to be in the other direction, extending the period
for comments, rather than reducing it.

If the only reason for this change is some desire to be consistent with
the rest of the IETF last call timeline, then that's misguided in the
extreme - first because there is no one last call period (there are
several, for different kinds of documents, and circumstances) and second,
because the 14 day LC period for IETF WG docs is set to match the IESG
meeting timetable, it allows the IESG to approve a last call on a doc at
one meeting, after which in the days that follow, the LC announcement is
actually issued.  Two weeks after that, the responsible AD can summarise
the LC results, and have the results available for the IESG at its next
meeting (that being 2 meetings after the LC approval was made).   There's
a reason for that particular period for most docs - it allows things to
move along without undue delay (after they've often been debated for a
year or more already.)

In general, I'm tempted to summarily reject any request for any change
(even fixing a simple spelling mistake) until I've seen an explicit
explanation for why the change is needed - that way I can evaluate whether
the proposal actually meets the stated objective, whether the objective
might perhaps be realised better via a different change, and even whether
the objective is desirable in the first place.

When all that is provided is "here is this list of changes" I have the
opportunity for none of that, so I can't possibly tell whether they're
reasonable or not, nor whether they are effective or not.

For now, make no changes at all.

kre

---

From: "Tom.Petch" <[email-masked]>
Date: Wed, 24 Jun 2009 10:50:37 +0200

----- Original Message -----
From: "Marshall Eubanks" <[email-masked]>
To: "ietf list" <[email-masked]>; "IAB IAB" <[email-masked]>; "IESG" <[email-masked]>
Cc: "Trustees" <[email-masked]>
Sent: Tuesday, June 23, 2009 7:32 AM
Subject: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

> proposed revisions are in rtf, pdf and doc formats and located at:
http://trustee.ietf.org/policyandprocedures.html
> has prohibited the making of derivative works.

I like this change because it also makes it clear that even when 6.c.iii clause
is included because RFC5378 rights have not been obtained, yet code can still be
modified outside the standards process.   The TLP currently in force gives my
lay mind the impression that that right had been withdrawn and my query about
this last February never got answered.  So yes, I like it.

Tom Petch

---

From: "Tom.Petch" <[email-masked]>
Date: Wed, 24 Jun 2009 11:25:32 +0200

---- Original Message -----
From: "Simon Josefsson" <[email-masked]>
Sent: Tuesday, June 23, 2009 5:30 PM

> me.

Mmmmm ... I think that one thing that the ipr working group got absolutey right
was the decision not to try and craft legally suitable wording for intellectual
property rights, rather delegating that task.

This sounds like a suggestion to restart the ipr wg, perhaps in the hope of
getting a different outcome:-)

I would however agree with the suggestion that a complicated (to me as a lay
person) document should be accompanied by a non-legally binding lay explanation,
eg as to why it is thought suitable to cut the review period from 28 to 14 days,
or why a reference to the BSD licence should be thought adequate.

Tom Petch

>  I suggested it earlier, and the IETF Trust response was at least

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 24 Jun 2009 15:17:05 +0200

> getting a different outcome:-)

I don't think that is the intention at all.  This is about the process
used by the IETF Trust.  Publishing material early and improving them
incrementally is something the IETF has been good at.

> or why a reference to the BSD licence should be thought adequate.

The problem with these non-binding documents is that they are often
inaccurate and it is difficult to reach closure on what should be in
them.  It may be better to keep the legally binding document as clear as
possible, and to get as many as possible to review and understand them.

/Simon

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Jun 2009 09:56:14 -0400

--On Tuesday, June 23, 2009 17:04 -0400 "Contreras, Jorge"
<[email-masked]> wrote:

>  
>> 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.
> 
> The Feb. 15 version of the TLP is currently in effect.
> Documents published between Feb. 15 and the effectiveness of
> the revised TLP will continue to be governed by the Feb. 15
> TLP.  There should be no gap in coverage.

I agree.  But that isn't what the document appears to say --
either to me or to an attorney friend to whom I showed it
yesterday (we were meeting about something else entirely, and
not in his lawyer capacity, but it seemed like an opportunity
for some quick calibration of whether my seeing the apparent
ambiguity was just my lack of legal training).

>> careful review of the proposed new procedures in toto.  

Glad to hear it.

    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Jun 2009 09:51:08 -0400

--On Wednesday, June 24, 2009 11:25 +0200 "Tom.Petch"
<[email-masked]> wrote:

>> I don't think you are alone with that impression.  The
>> process you outline (posting preliminary versions in draft-*
>> form) sounds great to me.
> 
> Mmmmm ... I think that one thing that the ipr working group
> got absolutey right was the decision not to try and craft
> legally suitable wording for intellectual property rights,
> rather delegating that task.

We certainly agree about that.  Indeed, I believe that, having
agreed to that principle, the IPR WG went too far toward
drafting legal language.

> This sounds like a suggestion to restart the ipr wg, perhaps
> in the hope of getting a different outcome:-)

No, at least not from me.  But the intention was that the IPR WG
establish principles for the IETF Track and then pass those
principles to the Trustees and IAOC, and have them implemented
in legal language, etc.  To the extent to which they got near
the other tracks, they were expected to be completely consistent
with the boundaries established by RFC 4484 and prior practice.
The WG did that job, independent of how one feels about the
decisions made and the quality of consensus about some of them.
I'm not questioning the WG process or decisions here.

However, this document contains provisions that are inconsistent
with WG guidance, inconsistent with 4844, or both.  Those
provisions also permit the Trust to take arbitrary actions in
the future with little transparency and no accountability.

One can certainly question that without trying to restart the
IPR WG or any similar effort.

> I would however agree with the suggestion that a complicated
> (to me as a lay person) document should be accompanied by a
> non-legally binding lay explanation, eg as to why it is
> thought suitable to cut the review period from 28 to 14 days,

Of course, the latter is appropriate for a lay explanation.  To
the extent to which the Trustees discussed the various
alternatives (noting that none of the actual Trustee are, as far
as I know, lawyers either), that is also appropriate because it
is not clear that anyone delegated that particular decision to
the Trustees and the community needs that information to
evaluate the proposal.

On the other hand, the 28 -> 14 change isn't a legal matter at
all.  It is simply a matter of IETF procedure and relationship
with the IASA.   While I think it represents depressingly poor
judgment and that it may be a symptom of the degree to which the
IASA has gotten out of touch with the community, I see nothing
improper with their proposing a 14 day review period or, if they
like, a three day review period to us... as long as we can say
"no".

     john