Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Olaf Kolkman writes: > On Sep 8, 2009, at 2:06 PM, Simon Josefsson wrote: > 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. >> >> 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. > > 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). 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
On Sep 8, 2009, at 2:06 PM, Simon Josefsson wrote: 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. 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. 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. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Henk Uijterwaal writes: > Simon Josefsson wrote: >> Marshall Eubanks 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. 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. >>> 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. 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. >>> 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Simon Josefsson wrote: Marshall Eubanks 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 NetherlandsThe NetherlandsMobile: +31.6.55861746 -- Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
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: ipr-wg-boun...@ietf.org [mailto:ipr-wg-boun...@ietf.org] On Behalf Of Tadayuki Abraham HATTORI Sent: Monday, August 17, 2009 8:14 PM To: Marshall Eubanks; ietf@ietf.org; Working Group Chairs Cc: Trustees; Internet Research Steering Group; IAB IAB; IESG; ipr...@ietf.org; RFC Editor Subject: Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP) 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" To: ; "Working Group Chairs" Cc: "Trustees" ; "Internet Research Steering Group" ; "IAB IAB" ; "IESG" ; ; "RFC Editor" Sent: Tuesday, August 18, 2009 12:02 AM Subject: Proposed Policy for Modifications to Trust Legal Provisions (TLP) > 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,
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
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
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
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. 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. 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. 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. 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
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
On Tue, Aug 18, 2009 at 04:50:59PM +0200, Simon Josefsson wrote: > and getting it published as an RFC should not be difficult. If it takes > 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 a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Brian E Carpenter writes: > On 2009-08-18 07:57, Simon Josefsson wrote: > ... >> 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? > > 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
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 Brian E Carpenter wrote: 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: ... 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? 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
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: ... > 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? 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
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" To: ; "Working Group Chairs" Cc: "Trustees" ; "Internet Research Steering Group" ; "IAB IAB" ; "IESG" ; ; "RFC Editor" Sent: Tuesday, August 18, 2009 12:02 AM Subject: Proposed Policy for Modifications to Trust Legal Provisions (TLP) 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 th
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
SM: 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. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
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. At 08:02 17-08-2009, Marshall Eubanks wrote: 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. 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. 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. 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. 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). In my opinion Item 3b is a resurrection of a previous proposal submitted by the IETF Trust to the IETF Community. 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. 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". 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). Wasn't there a decision where the IETF Chair determines the consensus? 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. 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 replaced by Trust. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Marc Blanchet writes: > Marshall Eubanks a écrit : >> >> On Aug 17, 2009, at 11:25 AM, Marc Blanchet wrote: >> >>> Marshall Eubanks a écrit : 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. >>> >>> 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. > > 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Marshall Eubanks a écrit : > > On Aug 17, 2009, at 11:25 AM, Marc Blanchet wrote: > >> Marshall Eubanks a écrit : >>> >>> 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. >> >> 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. 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. > > 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 >> >> -- = 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Marshall Eubanks a écrit : > > 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Dear Simon; Some quick responses just for myself only. On Aug 17, 2009, at 11:36 AM, Simon Josefsson wrote: Marshall Eubanks 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. I would like to understand why you believe this approach is not a more suitable 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. 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? 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. 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. 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. 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. Does this list exists now? Good catch. I thought it did. It will shortly. 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. I believe it needs be explicit that the reason has to be explained to 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 /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
On Aug 17, 2009, at 11:25 AM, Marc Blanchet wrote: Marshall Eubanks a écrit : 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. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
Marshall Eubanks 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. I would like to understand why you believe this approach is not a more suitable one than what you propose. > 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? > 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. 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. > 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. Does this list exists now? > 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. I believe it needs be explicit that the reason has to be explained to the community, not to only a smaller group. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Policy for Modifications to Trust Legal Provisions (TLP)
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" wrote: > 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 202
