Subject: Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 08 Sep 2009 13:54:23 +0200

Simon Josefsson wrote:
> Marshall Eubanks <[email-masked]> writes:
> 
>> Comments sought for:  Standard Procedure for Modifying the TLP
> 
> Is this a solution looking for a problem?  RFC 5377 is an example of
> where the IETF asks the Trust do something.  What is wrong with using
> the same approach in the future?   The approach would be that someone
> writes an I-D, there is IETF-wide last call on it, and it is either
> approved or not.   If it is approved, the Trust needs to act.

Correct and this document specifies how the trust will react: it takes
the guidance (for example, RFC 5377), modifies the text, gets legal
advice and proposes an implementation to the community.  The community
reviews the changes and checks that what is implemented, is what is
requested.

>> 2. Whoever brings up the problem, writes a problem statement.
>>    a. In case 1a: this can be an individual submission ID or a ID from
>> a WG
>>       chartered to discuss these items.
>>    b. In case 1b: A note from the trust to the community.
>>    c. In case 1c: A note from whoever brings up the issue.
> 
> For 2c, whom is the note to?  To only the trust or to the community?  If
> the former, will be trust communicate the request to the community?

2c are cases where the Trust manages something for another stream, so in
first order, I'd say that the note is for the trust and that other stream.
I don't see a problem sending it else where though.

> 
>> 4. Trust (with legal counsel) reviews the issue and comes up with a
>> response:
>>    a. No, we don't think changing this is a good idea, because ...
>>
>>    b. Yes, we suggest to modify the text as follows ... (perhaps with
>>       some background material why this is the answer).
> 
> I'm strongly concerned that this puts the decision making of what is and
> what is not a problem into the Trust's hands. 

No, there is always step 5: review of the new text or decision not to change
the text.  If a suggestion isn't considered a good idea by the Trust, the
reasons for not changing it can be discussed in this step.

The trust is there to protect the IPR held by the IETF, if the community
comes up with a suggestion that has a negative impact on that, I want the
Trust to be able to warn the community about this, rather than blindly
implement the change.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Belgium: an unsolvable problem, discussed in endless meetings, with no
          hope for a solution, where everybody still lives happily.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 08 Sep 2009 14:06:00 +0200

> reviews the changes and checks that what is implemented, is what is

I wish that is how it would work.  The most recent change of the TLP was
not following that process -- instead the Trust proposed the change and
implemented it after some delay -- and, for example, it resulted in a
change to how BSD licensed portions extracted from IETF documents that
is not consistent with common practice.

> I don't see a problem sending it else where though.

2c does not seem restricted for non-IETF streams from the writing above.
I think it is important that the IETF is notified for issues relating to
the IETF stream.

> reasons for not changing it can be discussed in this step.

Step 4 puts a veto for changes into the Trust's hands.  Members on the
Trust can be removed by the IETF, but I don't believe that is a good way
to make the Trust to do something the IETF requests.

/Simon

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 8 Sep 2009 14:56:07 +0200

> to make the Trust to do something the IETF requests.

As a Trustee I've signed a statement that reads:

  3. The undersigned hereby agrees to serve as a Trustee to the Trust  
and to fulfill the
     duties of a Trustee in accordance with the terms of the Trust  
Agreement and all
     other requirements of law applicable to service as a trustee of a  
Virginia trust and
     to comply with all requirements of the Trust Agreement applicable  
to his/her
     service as a Trustee

If a proposal from the IETF is in conflict with the terms of the Trust  
Agreement or the law then a Trustee has the obligation to veto it (a  
fairly academic possibility, I believe).

However, if such happens I think that the Trust has the obligation  
(MUST) to explain the motivations in quite some detail, and explain  
why they did not catch the problem earlier in the process.

--Olaf

________________________________________________________

Olaf M. Kolkman                        NLnet Labs
                                        Science Park 140,
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 08 Sep 2009 16:04:37 +0200

Simon,

> is not consistent with common practice.

That is correct.  One of the things we learned from the discussions around
the last TLP changes, was that there was no clear process to follow when
the TLP needs to be changed.  This proposal is there to fix that.

> I think it is important that the IETF is notified for issues relating to

2c says case 1c, 1c deals with all non IETF streams that the Trust manages.

(For the last point, please see Olaf's mail.)

Henk

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 08 Sep 2009 17:26:42 +0200

> fairly academic possibility, I believe).

I don't see how that is related to step 4 above.  There is plenty of
mechanisms left for the Trust to veto changes to become effective -- for
example, you can just refuse to approve the change -- however my point
is about having the trust be able to cancel the process to modify the
TLP even before it has been subject to community discussion.  That
approach appears contrary to the concept that the Trust carries out the
wishes of the IETF and not the other way around.

/Simon

---

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 08 Sep 2009 17:55:31 +0200

> wishes of the IETF and not the other way around.

I don't see how this is possible:  If the community believes that a
change should be made, the Trust has to (at least) review it and
explain why it believes that this is not a good idea.  This brings
us to phase 5, community discussion, where one can discuss the
arguments for not making the change.

At this point several things can happen.  One possibility is that the
community really wants the change but the Trust doesn't.  In that
case, there is an possibility for appeal.

Henk

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 08 Sep 2009 18:02:40 +0200

> arguments for not making the change.

Exactly.  What step 4 does is to allow the trust to cancel the community
review by declaring that it doesn't agree.

> case, there is an possibility for appeal.

Step 6 allows the trust to evaluate the community request and veto the
request if needed.

What I'm objecting to is to allow the trust to veto the TLP changes as
early as step 4, before there has been community review of the proposal.

/Simon