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: Stephan Wenger <[email-masked]>
Date: Mon, 17 Aug 2009 17:29:08 +0200

Hi Marshall, all,

This is a good proposal.

Would it be possible to enhance the review periods (steps 5 and 6) from
30/14 days to something like 60/30 days, respectively?  Many people will
need to go through corporate counsel on matters like this, which can be time
consuming.  30 days is a quite typical vacation period in many European
countries.  And, for emergencies, there is the emergency procedure with 14
days review period (which I do not propose to adjust).

Regards,
Stephan

On 8/17/09 5:02 PM, "Marshall Eubanks" <[email-masked]> wrote:

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 17 Aug 2009 17:36:43 +0200

> 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.  I would
like to understand why you believe this approach is not a more suitable
one than what you propose.

>    a. In case 1a: this can be an individual submission ID or a ID from
> a WG

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?

>       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.  I don't believe this was
the intention when the Trust was formed.  As far as I understood the
background for the Trust, it was not to control the IETF, it was to
cater for the wishes of the IETF in (mostly) copyright areas.  The
approach here appears contrary to this role.

>   the equivalent for the other streams.  Discussion will take place

Does this list exists now?

>   Trust must explain the reason for the change.

I believe it needs be explicit that the reason has to be explained to
the community, not to only a smaller group.

/Simon

---

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

On Aug 17, 2009, at 11:25 AM, Marc Blanchet wrote:

> Marshall Eubanks a écrit :
>>
> 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.
>

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

> 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 12:11:20 -0400

Dear Simon;

Some quick responses just for myself only.

> one than what you propose.

The Trust has received requests from, for example, the other stream  
editors. We have received
complaints about the way these were dealt with. This is an attempt to  
address those complaints.

> the former, will be trust communicate the request to the community?

I think that if the note is to the Trust, it will have to be  
disseminated to the community as part of the process and that should  
be made clear here.

> Does this list exists now?

Good catch. I thought it did. It will shortly.

> the community, not to only a smaller group.

Good catch. Speaking just for myself, I agree. And, still speaking  
just for myself, I regard an emergency
as something on the lines of "we are receiving legal cease and desist  
orders and court summons" and not much
short of that.

Marshall

---

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

timely change in the TLP which would likely require a lot of heavy legal

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

Marc.

---

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: Simon Josefsson <[email-masked]>
Date: Mon, 17 Aug 2009 21:57:04 +0200

> document and we don't want to change it over night.

This is another reason why the current approach of getting IETF
consensus on an RFC and publishing should be preferred.  Compare RFC
5377.  It is a well defined process, and unless there is consensus that
the approach is broken I believe we should use the normal process.  Can
we start and agree on a problem statement before finding solutions?

/Simon

---

From: SM <[email-masked]>
Date: Mon, 17 Aug 2009 14:13:55 -0700

Hi Marshall,

I'll take this opportunity to say that I was pleasantly surprised to 
hear that the IETF Trust implemented a IETF Trust Records Retention 
and Management Policy over two years ago.

>       independent stream, etc) for which the trust manages something.

Does the IETF Trust want to stand in as a replacement for the old IPR WG?

Some subset of the community will always want something 
different.  We already know what happened the last time that happened.

>    c. In case 1c: A note from whoever brings up the issue.

The IETF Trust is directed by the IETF Community.  It's not for WGs 
or individuals to write problem statements for the IETF Trust.  If 
there is a problem, they take it to the IETF Community and it goes 
through normal channels to the IETF Trust.

>       a short comment period (2 weeks).

In my opinion Item 3b is a resurrection of a previous proposal 
submitted by the IETF Trust to the IETF Community.

>    and reset the counter before the comment period is over.

Please do not reset the counter.  If the IETF Trust believes that it 
is a bad proposal, it can withdraw it.  When a proposed decision is 
going to affect the wider community, it should not be treated as a 
"Work in Progress".

>    c. There is no consensus => drop proposal (and explain why).

Wasn't there a decision where the IETF Chair determines the consensus?

>   Trust must explain the reason for the change.

If the IETF Community believe that there is a need for a special 
procedure to deal with emergencies, it can craft one up.  I don't 
know what you expect to get done in two weeks which you cannot do in 
four weeks.

>Appeals: use the process from RFC 4071 for the IAOC, with IAOC

The subject line mentions a "proposed policy".  Does that mean that 
there isn't a procedure in place for the IETF Trust to consider an 
appeal at the moment?

Regards,
-sm

---

From: Russ Housley <[email-masked]>
Date: Mon, 17 Aug 2009 19:53:47 -0400

>Does the IETF Trust want to stand in as a replacement for the old IPR WG?

Certainly not.  The changes that people might suggest to the TLP 
should be much less grand.

Russ.

---

From: "Tadayuki Abraham HATTORI" <[email-masked]>
Date: Tue, 18 Aug 2009 09:13:49 +0900

Dear experts,

Generally, the idea of "provision" includes a kind of "bad debt allowance"
in accounting. How about expanding the idea of  "Trust Legal Provision"?

Gathering statistically of mathematical probability of how setting for bad
debt allowance could be a kind of measurement of ability of estimation
by executives of a corporation.

The best way to growup equity is good choice of executives according to
the ability of estimation.

Standard deviation of probability of adequateness of setting of provisions,
or bad debt allowance at begining could be useful for making the world to
be more better.

I THINK.

regards,

Tadayuki Abraham HATTORI

----- Original Message ----- 
From: "Marshall Eubanks" <[email-masked]>
To: <[email-masked]>; "Working Group Chairs" <[email-masked]>
Cc: "Trustees" <[email-masked]>; "Internet Research Steering Group" 
<[email-masked]>; "IAB IAB" <[email-masked]>; "IESG" <[email-masked]>; 
<[email-masked]>; "RFC Editor" <[email-masked]>
Sent: Tuesday, August 18, 2009 12:02 AM
Subject: Proposed Policy for Modifications to Trust Legal Provisions (TLP)

> 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.
>
> 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
>
>    a. In case 1a: this can be an individual submission ID or a ID  from a 
> WG
>    a. If the problem statement was developed in a group effort, then  it 
> is by
>       default.
>    If the comments show a clear trend indicating that the proposal  needs
>    a revision, the Trust may withdraw or modify the proposal, publish  it

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Aug 2009 12:54:06 +1200

I agree with the proposed policy, except that I propose
calling it just "Procedure". It isn't policy, it's just
common sense about how to implement policy.

On 2009-08-18 07:57, Simon Josefsson wrote:
...
> we start and agree on a problem statement before finding solutions?

It would be serious overkill to do this for trivial legal verbiage changes,
which is what we've been discussing for the last 9 months. As Russ implied,
a change of actual *IPR policy* for the the IETF would be an IETF matter;
we're talking here about the Trust's implementation of that policy, or
of policies for the non-IETF document streams, via the TLP. Even an I-D
could be overkill for verbiage changes.

Along the same lines, an emergency procedure is entirely appropriate,
and well within the policy created by RFC4748 and 5378.

    Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 17 Aug 2009 22:10:58 -0400

I would agree with Brian, but phrase it differently.

The Trust Legal Provisions document specifies exactly how the trust, and 
people acting based on the trust, are doing things.

There are (at least) two kinds of changes that can occur.
1) There can be changes in policy, particularly policy as it affects 
IETF documents.  Policy changes that affect the IETF have to come from 
the IETF, with sufficient clear community support (at least to the level 
of rough consensus) for the trust to act on.
2) There can be changes of mechanism.  The trust could learn that the 
mechanism that it adopted has a flaw.  For example, RFC 5377 
specifically leaves the marking determination and legal writing to the 
trust.  Within a defined policy.  If the trust determines it needs to 
change its mechanism, the whole point of that structure was to not need 
a new RFC.  But it does require checking with the community to make sure 
that there are no surprise (in particular, this space is full of 
unanticipated side-effects.  More eyes can help with that.)

So the trust does need some procedure by which it checks with the 
community that mechanism changes are acceptable.
The published steps look reasonable to me.

Note that it is perfectly reasonable (but I hope and expect very rare) 
for someone in the public review cycle to say "hey, you are changing the 
policy (not just mechanism) we all told you about."  In which case, 
assuming other folks agree, the ballgame changes.

Yours,
Joel

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Aug 2009 16:50:59 +0200

Brian E Carpenter <[email-masked]> writes:

> which is what we've been discussing for the last 9 months.

Trivial verbiage changes can have significant practical consequences.
If there is consensus around a trivial change, writing an I-D about it
and getting it published as an RFC should not be difficult.  If it takes
9 month to get that done, something else is broken.  I don't see how
specifying an alternative publication and consensus gathering path for
the Trust will avoid the same problem.

/Simon

---

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 18 Aug 2009 12:25:44 -0400

On Tue, Aug 18, 2009 at 04:50:59PM +0200, Simon Josefsson wrote:

> 9 month to get that done, something else is broken.

One might be tempted to argue, indeed, that what is broken is the
proliferation of policies, written procedures, and other
administrative hurdles that large and mature organizations tend to
build for themselves.  These start as an effort to make rules so that
the activities of the organization are consistent and low-cost, but
the imperfection of the rules tends to cause effort to be spent on
perfecting the rules.  That attention to rule-perfection takes
attention from the very activity the rules were meant to facilitate.
I leave it to the gentle reader to evaluate to what extent the current
state of affairs matches that description.

A

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

---

From: SM <[email-masked]>
Date: Tue, 18 Aug 2009 13:33:31 -0700

Hello,
At 19:10 17-08-2009, Joel M. Halpern wrote:
>The Trust Legal Provisions document specifies exactly how the trust, 
>and people acting based on the trust, are doing things.

 From Section 2e of the IETF Trust License Policy:

  "These Legal Provisions may be amended from time to time by the IETF Trust
   in a manner consistent with the guidance provided by the IETF community
   and its own operating procedures."

 From Item 10 of the Administrative Procedures of the IETF Trust:

  "The Trust shall be guided by IETF process documents, decisions of the
   IETF leadership, and IETF consensus when licensing use of its
   intellectual property in accordance with the Trust Agreement."

I'll mention a sentence from Item 11:

  "All the Trustees' decisions shall be subject to the community review
   process defined in Section 3.5 of BCP 101 for IAOC decisions."

One of the advantages of restricting how the IETF Trust operates is 
that it can also protect the IETF Trust.

>IETF documents.  Policy changes that affect the IETF have to come 
>from the IETF, with sufficient clear community support (at least to 
>the level of rough consensus) for the trust to act on.

I gather that by the above, Joel means that clear community support 
is given through a BCP.  If I misunderstood, please clarify how the 
clear community support is determined and by whom.

>2) There can be changes of mechanism.  The trust could learn that 
>the mechanism that it adopted has a flaw.  For example, RFC 5377 
>specifically leaves the marking determination and legal writing to 
>the trust.  Within a defined policy.  If the trust determines it 
>needs to change its mechanism, the whole point of that structure was 
>to not need a new RFC.  But it does require checking with the 
>community to make sure that there are no surprise (in particular, 
>this space is full of unanticipated side-effects.  More eyes can 
>help with that.)

I'll quote a message [1] from an IETF participant:

  "When the Trust was formed a number of us were quite worried that it
   would begin to see itself as self directed and not as a function whose
   purpose was to act at the direction of and in support of the IETF."

As far as I am aware that is not mentioned in any RFCs or the IETF 
Trust Agreement.  I am not going to argue with the IETF participant 
who made that statement as I believe that I can learn from the 
experience of others, whether they are young and less young, even if 
what they say is not a "standard of any kind".

If you want to accuse me of selective quoting, I'll mention that I 
would have quoted other sections of that message and other messages 
if I were to follow the advice of old Fairford (note that the latter 
is not an IETF participant).

I hereby elect not to invoke any rights under the Internet Standard 
Process in relation to this message.  Please feel free to say 
whatever crosses your mind.

>The published steps look reasonable to me.

The subject line of the message posted by the IETF Trust Chair says 
"Proposed Policy for Modifications".  If the IETF Trust is to deal 
with legal aspects, I assume that it will have weighed whether its 
proposal is about procedures (how things work in practice) or 
policies.  As the messages states that it is "proposed policy", I 
will consider it as such.

>Note that it is perfectly reasonable (but I hope and expect very 
>rare) for someone in the public review cycle to say "hey, you are 
>changing the policy (not just mechanism) we all told you about."  In 
>which case, assuming other folks agree, the ballgame changes.

As few days ago, Joel mentioned that there are two arguments being 
made and I preferred not to argue about them.  However, the recent 
events have prompted me to rethink that.  I believe that the IETF 
Trust is changing the policy and not just the mechanism.  Saying that 
the IETF Trust has gone rogue might capture the attention of IETF participants.

I'm going to rehash the "obnoxious license" thread.

Andrew Sullivan asked 'Why not have these "stable" licences published 
in RFCs'. [2]

The answer is because it is not convenient, depending on where you 
stand, to update RFCs as they have to go through the Process.  The 
Process intentionally has safeguards so that changes are carefully 
reviewed and are seen as the consensus of the IETF Community.  I 
believe that it would be better to have these licenses in RFCs as 
they are a stable reference.  RFCs are also widely disseminated and 
can be accessing using various protocols.  There are disadvantages, 
depending on your viewpoint, to putting these documents on one web 
site as it is one point of access and it is not possible to determine 
whether the document has been modified (I do not believe that the 
IETF Trust would resort to that but that's not the point).  The 
persons controlling the web site also have full control over the changes.

As a side note for the Open Source folks, I'll comment on license by 
reference.  The Apple's Common Documentation License v1.0 refers to 
http://www.opensource.apple.com/cdl  You won't find that page there.

John Levine mentioned that the ABNF is only two lines of 
code  [3].  I'll leave it to you to determine the absurdity of having 
a 32 line license for two lines of code.  It is good to acknowledge 
the source.  However, if we had to use the same rule as for code, 
most of the content of a RFC would be acknowledgements.

Sean Turner mentioned [4] that the IESG added RFC editor notes to the 
ASN.1 modules in a document.  The message from the IESG was on May 
15.  Joel mentioned that the trust procedures no longer require those 
license statements in RFCs.  The "Code Components List" has been 
effective as from April 23.  I have some doubts about whether we can 
invoke "overcome by events" (OBE) for such a case.  If you are going 
to tell me that the IESG is not aware of what the IETF Trust is 
doing, please do not expect the IETF Community to be better informed.

John Klensin filed an appeal on July 18 which is exactly one month 
ago.  I am waiting to see whether the appeal will be OBE.

We generally refer to RFCs in our arguments as they are a way to 
document the thoughts of the IETF Community.  In the case of the IETF 
Trust, I don't know whether the BCPs take precedence over the IETF 
Trust Agreement.  I am not comfortable with claims made based on 
documents which are not BCPs as it falls foul of the spirit of how 
the IETF has been doing business up to now.  An overtly legal 
approach might made sense if we want to avoid litigations but it 
requires a cultural change within the IETF.  Once we cross that 
bridge, there is no going back.  Some people may argue that the IETF 
is operating in a hostile environment and that it is in the best 
interest of the IETF to take that path.  I'd say that we can always 
look for an environment which is better aligned to IETF 
culture.  That culture is changing but that's another story.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg57650.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg57969.html
3. http://www.ietf.org/mail-archive/web/ietf/current/msg57986.html
4. http://www.ietf.org/mail-archive/web/ietf/current/msg57984.html

---

From: John C Klensin <[email-masked]>
Date: Wed, 19 Aug 2009 00:46:22 -0400

Marshall,

My apologies for not responding sooner to this.  I've been in
offsite meetings for the last two days with very limited email
access and have only now been able to study your message and
scan the subsequent comments.  Several aspects of these comments
have been influenced by those other notes.

I think this proposed policy still reflects the core problems
that caused my still-pending appeal.

I want to try to state a few principles that generalize from the
IETF-specific provisions and language of 5378 to the other
streams, work around a problem in the way 5378 interpreted what
I believe was the conceptual intent of the WG, and provide a
basis for moving forward.

(1) The Trust does not make policy.  The Trust is an implementer
of policies set by the various streams.  As part of that
implementation process, the Trust is inevitably going to need to
interpret the stream-set policies and generate details and
specific procedures, but even those are subject to review by the
relevant streams.

There is obviously a line between policies and policy decisions
and implementation of policies and determination of details.  I
think we can trust the Trustees to use good sense about that
(subject to appeal) as long as there is general agreement on
these principles.  I think that where we are hung up now is that
many of us believe, based on the provisions of BCP 101 and a
general sense of the consensus of the community both when  the
IASA was established and now, that the Trust doesn't make
policy.  By contrast, the Trustees appear to be making
statements and proposing policies (including this latest draft)
that make them both determiners of policy and of consensus in
bodies whom they are not chosen to represent.

(2) The Trust is not set up to be an interpreter of consensus of
the bodies associated with any particular stream.  In general,
each stream has its own mechanism for making consensus
determinations.  If those mechanisms are inadequate in any way,
the problem is not the Trust's to solve.

(3) A corollary to the Trust's role as an implementer of
policies is that the Trust and its Counsel have a key role in
determining the feasibility of policy decisions coming from the
streams.  If the Trust determines that a particular policy
cannot be implemented without negative legal consequences or
significant negative procedural ones, then the Trust can, and
should, bounce the policy back to the originating stream with an
explanation.   It may be useful to think of that "bouncing"
process as as an appeal from the Trust to the Stream, but an
appeal that is explicitly of the character of "you missed some
important issues when you agreed to this and sent it to us, here
are the issues, please rethink your decision".   While it is
obviously desirable to have that sort of response on a timely
basis, there should not be a fixed time limit.

I note that application of (3) would have prevented the
situation in which the Trust felt obligated to try to enforce a
narrow reading of 5378, with that enforcement effective at a
time when the Trustees and community already understood that
doing so would cause fairly serious problems.

In broad outline, where the above would take us as a Trust
procedure for dealing with policy changes is:

(i) Policy change suggestions originate with the streams.  It is
their responsibility to determine what is important and what is
not and to determine whether they have sufficient consensus for
a change.  If the Trustees determine that changes are needed for
a particular stream, they are free to propose those changes to
the body responsible for the stream, using the processes of that
body.  Typically they will act as individual participants in the
work associated with that stream or, if necessary, by generating
suggestions transmitted as liaison notes (if the latter were
needed very often, I think it would be a sign that we had
succumbed to terminal bureaucracy).

(ii) When the body associated with a stream concludes that it is
ready to establish a new policy, that policy is submitted to the
Trustees (and, presumably, to Counsel) for review and comment
(not approval -- whether the Trustees "like" the policy or not
is not at issue here).   If the Trustees believe the policy can
be implemented in a way that is legally and procedurally sound,
they proceed to drafting such implementation details are
appropriate.  Those details are then presented back to the
relevant stream body for approval and signoff (or rejection and
either adjustment of the policy or further discussion).   If the
Trustees believe that the policy cannot be implemented in a
legally and procedurally sound way, they return the policy
specification to the stream body with an explanation adequate to
enable that body to perform a thoughtful and informed review and
reevaluation.

That is all.  The key issue, as others have suggested both in
the discussion on this thread and in earlier ones, is that there
is no problem until some stream (or the approving bodies and
processes for that stream) are convinced that there is a
problem.  Except in real emergencies, if the Trustees are
convinced that there is a problem, their job is to convince the
stream, not to start making policy.

And, yes, I think there needs to be a provision for rapid action
in an emergency.  If it is ever exercised, I think the Trustees
should feel considerable obligation to be exceptionally open and
transparent and to devise a solution that whose reversal would
cause as little damage as possible if the relevant community
eventually decided that a different solution was appropriate.
And I would assume that the relevant communities would deal with
any regular pattern of abuse of emergency provisions with
extreme hostility.

I note, because he and I often disagree on these matters, that...

--On Monday, August 17, 2009 22:10 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

> 1) There can be changes in policy, particularly policy as it
> affects IETF documents.  Policy changes that affect the IETF
> have to come from the IETF, with sufficient clear community
> support (at least to the level of rough consensus) for the
> trust to act on.

> 2) There can be changes of mechanism.  The trust could learn
> that the mechanism that it adopted has a flaw.  For example,
> RFC 5377 specifically leaves the marking determination and
> legal writing to the trust.  Within a defined policy.  If the
> trust determines it needs to change its mechanism, the whole
> point of that structure was to not need a new RFC.  But it
> does require checking with the community to make sure that
> there are no surprise (in particular, this space is full of

I think we are in complete agreement about the above and that my
comments and stated principles at the beginning of this note are
a generalization of Joel's categorization to apply separately to
each stream.

    john

---

From: "Endre Jarraux Walls" <[email-masked]>
Date: Tue, 18 Aug 2009 13:47:45 -0400

Tadayuki,

I read your email and am totally scratching my head - not sure where you're
going with that at all.

A point was made earlier by Marc as to what the case would be for an
emergency process to what should be a stabilized process requiring
thoughtful and consistent consideration. I do not know if that question has
been answered; I believe that's the question that really should be answered
here. Why would we need an emergency provision (under what circumstances)?
Also, with the idea of emergency provisions will we identify what qualifies
an issue as falling under the umbrella of requiring this type of
consideration?

My apologies if these questions have been answered; reading Marc's post I
found myself agreeing on the fuzziness of the whole issue.

Regards,

Endre Jarraux Walls

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tadayuki Abraham HATTORI
Sent: Monday, August 17, 2009 8:14 PM
To: Marshall Eubanks; [email-masked]; Working Group Chairs
Cc: Trustees; Internet Research Steering Group; IAB IAB; IESG;
[email-masked]; RFC Editor
Subject: Re: Proposed Policy for Modifications to Trust Legal Provisions
(TLP)

Dear experts,

I THINK.

regards,

Tadayuki Abraham HATTORI

----- Original Message ----- 
From: "Marshall Eubanks" <[email-masked]>
To: <[email-masked]>; "Working Group Chairs" <[email-masked]>
Cc: "Trustees" <[email-masked]>; "Internet Research Steering Group" 

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipr-wg

__________ Information from ESET Smart Security, version of virus signature
database 4346 (20090818) __________

The message was checked by ESET Smart Security.

http://www.eset.com

__________ Information from ESET Smart Security, version of virus signature
database 4346 (20090818) __________

The message was checked by ESET Smart Security.

http://www.eset.com