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-bounces@xxxxxxxx [mailto:ipr-wg-bounces@xxxxxxxx] On Behalf Of Tadayuki Abraham HATTORI Sent: Monday, August 17, 2009 8:14 PM To: Marshall Eubanks; ietf@xxxxxxxx; Working Group Chairs Cc: Trustees; Internet Research Steering Group; IAB IAB; IESG; ipr-wg@xxxxxxxx; 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" <tme@xxxxxxxxxxxxxx> To: <ietf@xxxxxxxx>; "Working Group Chairs" <wgchairs@xxxxxxxx> Cc: "Trustees" <trustees@xxxxxxxx>; "Internet Research Steering Group" <irsg@xxxxxxx>; "IAB IAB" <iab@xxxxxxx>; "IESG" <iesg@xxxxxxxx>; <ipr-wg@xxxxxxxx>; "RFC Editor" <rfc-editor@xxxxxxxxxxxxxx> 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 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. > > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ipr-wg mailing list Ipr-wg@xxxxxxxx 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 _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf