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

From: Marshall Eubanks <[email-masked]>
Date: Mon, 17 Aug 2009 11:02:40 -0400

Greetings;

During the last review of the Trust Legal Provisions (TLP),
it became clear that there is no clear
procedure for modifying the TLP.  The current TLP only states that a new
version may be published for community review but not who can ask for  
a change,
where announcements are sent, where the changes can be discussed and  
many
other things.  As a consequence, there have been questions about why  
the IETF Trust is proposing changes to the TLP, the problems that the  
changes fix, and the consequences of the changes.

In order to solve this problem, we have drafted a conceptual procedure  
for modifying
the TLP in the future.  This procedure can be found below.  We want to  
engage in a dialogue on these general concepts. Note that in items  
1,2,3,4 and 6, there is an implicit "Or" between each of the choices.

Assuming that consensus on the general ideas can be reached, the Trust
will submit a document describing this process in mid-September, 2009.  
I invite
interested parties to read and comment. This will be disseminated to  
the IETF Discuss and announce list, WG Chairs list, the old IPR WG  
List, the RFC Editor List and the IESG, IAB and IRSG lists. Please  
feel free to disseminate it to other interested parties, and please  
let me know if I left out a suitable list to alert.

Regards
Marshall Eubanks

-----------------------------------------------------
Comments sought for:  Standard Procedure for Modifying the TLP

1. An issue with the current TLP is identified:
    a. (Some subset of) the community wants something different from
       what the TLP currently says.
    b. The trust (or its legal counsel) finds a problem itself.
    c. There is a request from one of the other bodies (IRTF, IAB, IESG,
       independent stream, etc) for which the trust manages something.

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.

3. Is it really a problem?
    a. If the problem statement was developed in a group effort, then  
it is by
       default.
    b. All other cases, including issues brought up by the Trust  
themselves,
       a short comment period (2 weeks).

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).

5. 30 day community review period of the proposed changes (or decision  
not
    to change).

    The trust will engage in discussion with the community.

    If the comments show a clear trend indicating that the proposal  
needs
    a revision, the Trust may withdraw or modify the proposal, publish  
it
    and reset the counter before the comment period is over.

6. Trust evaluates responses.  Possible outcomes are:
    a. There is consensus about the change => Go to 7.
    b. There is consensus but textual changes are needed =>
       Trust modifies the text, go back step 5, but with a 14 day
       review period.
    c. There is no consensus => drop proposal (and explain why).

7. Publish new TLP.

Announcements: All announcements to go to the ietf-announce list plus
   the equivalent for the other streams.  Discussion will take place
   on the TLP mailing list.

Emergencies.  An emergency is defined as "there is a problem with the
   TLP that is likely to be abused".  In these cases, the trust can  
publish
   a modified text for a 2 week review period, then modify the TLP.  The
   Trust must explain the reason for the change.

Appeals: use the process from RFC 4071 for the IAOC, with IAOC
   replaced by Trust.

   If a member of the community is not satisfied with the Trusts's
   response to his or her review request, he or she may escalate the
   issue by appealing the decision or action to the IAB, using the
   appeals procedures outlined in RFC 2026 [RFC 2026].  If he or she is
   not satisfied with the IAB response, he or she can escalate the issue
   to the ISOC Board of Trustees, as described in RFC 2026.

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 17 Aug 2009 11:25:10 -0400

Marshall Eubanks a écrit :
>   TLP that is likely to be abused".  In these cases, the trust can publish

I have a hard time thinking of an emergency that can be fixed by a
timely change in the TLP which would likely require a lot of heavy legal
advice and related work and coordination. Changes in policies may have
important impacts over time that would probably require enough time to
review. To me, the TLP should be a pretty stable document.

However, I might think of an emergency for a immediate legal action, but
not sure about an emergency change in the TLP.

I guess I need to be educated on the use case for the emergency track.

Marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 17 Aug 2009 11:49:04 -0400

> I guess I need to be educated on the use case for the emergency track.

My personal feeling is that we won't really know until we have had a  
few, which hopefully will take
a very long time. But, it seems worthwhile to have some sort of "in  
case of emergency, break glass"
procedure.

And, I agree, I hope that the TLP becomes a very stable document.

Regards
Marshall

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 17 Aug 2009 11:56:17 -0400

Marshall Eubanks a écrit :
> a very long time. But, it seems worthwhile to have some sort of "in case
> of emergency, break glass"
> procedure.

the other side of the argument is being: the TLP is so central and
important that if one wants to change it, it has to go through a
somewhat "not fast" concensus-based process. i.e. this is a stable
document and we don't want to change it over night.

I still need to be educated for the use case of the emergency track.
Maybe I'm the only one here.

Marc.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 17 Aug 2009 12:09:22 -0400

On Mon, Aug 17, 2009 at 11:25:10AM -0400, Marc Blanchet wrote:

> advice and related work and coordination.

I had the same reaction.  I have a feeling that if there was in fact
such an emergency that called for urgent changes to the TLP, then the
real answer would be "stop accepting contributions until this is
fixed".  For practical purposes, this would mean that all mailing
lists would immediately become moderated or even closed, that no
meetings could happen, and that no new I-D submissions could be
accepted.  It would be pretty bad.

Now, the suggestion in the draft outline is, "A situation that is
likely to be abused."  It is almost certain that there is a loophole
that someone could detect and exploit.  It is my view that any such
loophole that isn't bad enough to warrant stopping contribution is
also not so bad that we need to rush through changes to the TLP, even
if that means that the exploitation can happen.  We'd have to suck it
up and say, "Too bad."  Even hurried changes to protocols around here
take months and sometimes contain regrettable errors, and that's an
area in which we are (collectively) reputedly experts.  I think
hurrying through a legal change in such an emergency is a really bad
idea, given the IETF partipants.

Note that I argue this way _for the IETF_.  In a company or even a
regular membership organization, I am not sure the same considerations
would apply.  But the IETF is unusual enough that we shouldn't expect
quick legal changes ever.

A

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

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 17 Aug 2009 18:55:19 -0400

The tlp-interest mail list is now active, for people who wish to  
discuss TLP issues there.

https://www.ietf.org/mailman/listinfo/tlp-interest

Regards
Marshall

On Aug 17, 2009, at 11:02 AM, Marshall Eubanks wrote:

> version may be published for community review but not who can ask  
> for a change,
> the IETF Trust is proposing changes to the TLP, the problems that  
> the changes fix, and the consequences of the changes.
>
> In order to solve this problem, we have drafted a conceptual  
> procedure for modifying
> the TLP in the future.  This procedure can be found below.  We want  
> to engage in a dialogue on these general concepts. Note that in  
> items 1,2,3,4 and 6, there is an implicit "Or" between each of the  
> choices.
>
> will submit a document describing this process in mid-September,  
> 2009. I invite
> 5. 30 day community review period of the proposed changes (or  
> decision not
>   to change).
>