Re: secdir review of draft-ietf-netconf-partial-lock-09.txt
Stephen As Dan and Bert think and believe, I guess #1. My experience with other technologies is that where enterprise systems are involved, then authorisation is likely to be powerful and comprehensive (and proprietary) but where network and operators are involved, then this is not so. Tom Petch - Original Message - From: "Romascanu, Dan (Dan)" To: "Stephen Hanna" ; "Tom.Petch" ; ; ; Sent: Thursday, August 13, 2009 1:10 PM Subject: RE: secdir review of draft-ietf-netconf-partial-lock-09.txt Steve, I believe that the situation is #1 below. Dan > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Stephen Hanna > Sent: Thursday, August 13, 2009 1:53 PM > To: Tom.Petch; sec...@ietf.org; ietf@ietf.org; > draft-ietf-netconf-partial-l...@tools.ietf.org > Subject: RE: secdir review of draft-ietf-netconf-partial-lock-09.txt > > Tom, > > Thanks for responding to my comments. Allow me to respond. > > You wrote: > > As a participant in netconf, I see authorization as one of those > > topics which the Working Group sees as necessary but cannot > be tackled > > just yet. As RFC4741 says, " This document does not specify an > > authorization scheme, as such a > >scheme should be tied to a meta-data model or a data model." > > and as yet, there is no data model; hence, no > authorization, not yet, > > nor, IMHO, for some time to come. > > This is just the sort of background information that a WG > participant would know but that a secdir reviewer would not. > Please allow me to ask a clarifying question. You say that > there is no authorization yet. > I think that could mean several things: > > 1) Existing NETCONF implementations implement authorization, ensuring >that each user gets an appropriate and perhaps different level of >access to the database. However, there are no standards for the >manner in which authorization is performed or configured. > > 2) Existing NETCONF implementations require authentication > but generally >just give complete read-write access to the database to > all authenticated >users. > > 3) Existing NETCONF implementations do not require authentication. >Anyone with network access has complete, unfettered access to >the database and can modify it at will. > > Could you tell me which of these meanings is most accurate? > Of course, it could be a mix of these but I'd like to get > your real-world assessment of the state of the NETCONF world. > If the answer is 3), we have a serious problem! If the answer > is 1) or 2), that's acceptable in my view. > > Now on to the language in the draft. My comment was relating > to this quote from the Security Considerations: > > > "Only an authenticated and authorized user can request a partial > > lock." > > I'm afraid that this statement is not justified if there is > no normative text requiring implementations to comply. I > suggest that normative text be added to at least require > authentication. > With such text, the statement above could be justified. > Requiring that levels of authorization be implemented is less > important in this application. And standardizing the manner > in which authorization is performed or configured (which I > think is your concern with respect to the lack of a data > model) is really not important at all unless NETCONF > customers or vendors decide that it is. Standardizing an > authorization policy format is a tremendously challenging > task for any protocol and often not necessary. > > I hope that this helps you address my comments in a > reasonable and achievable manner. The intent of secdir > comments is not to impose unreasonable requirements. It is to > point out issues that might not be evident to someone who is > not a security expert. > > Thanks, > > Steve > > > -Original Message- > > From: Tom.Petch [mailto:sisyp...@dial.pipex.com] > > Sent: Thursday, August 13, 2009 4:00 AM > > To: Stephen Hanna; sec...@ietf.org; ietf@ietf.org; > > draft-ietf-netconf-partial-l...@tools.ietf.org > > Subject: Re: secdir review of draft-ietf-netconf-partial-lock-09.txt > > > > - Original Message - > > From: "Stephen Hanna" > > To: ; ; ; > > > > Sent: Monday, August 10, 2009 4:28 PM > > > > > I have reviewed this document as part of the security > directorate's > > > ongoing effort to review all IETF documents being > processed by the > > > IESG. These comments were written primarily for the > benefit of the > > > security area directors. Document editors and WG chairs > > should treat > > > these comments just like any other last call comments. > > > > > > This document defines optional partial-lock and partial-unlock > > > operations to be added to the NETCONF protocol. These > operations are > > > used to lock only part of a configuration datastore, allowing > > > multiple management sessions to modify the configuration > of a device > > > at a single time. > > > > > > The Security Considerations section of the
Re: Gen-ART review of draft-ietf-vcarddav-webdav-mkcol-05
Spencer Dawkins wrote: ... 3. WebDAV extended MKCOL The WebDAV MKCOL request is extended to allow the inclusion of a request body. The request body is an XML document containing a single DAV:mkcol XML element as the root element. The Content-Type Spencer (minor): if I'm reading this paragraph correctly, I'd suggest "The request body is an XML document that MUST contain a single DAV:mkcol XML element as the root element" here - the last sentence in this paragraph makes me think the requirement is normative, but it doesn't look normative to 2119 scanners :-) ... -0.5 As far as I can tell, it is a myth that things can only be normative when using RFC 2119 keywords. As a matter of fact, RFC 2119 points out: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. So I'd prefer document authors to be more conservative in using those terms... BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-vcarddav-webdav-mkcol-05
Hi, Julian, I agree with your point here (on how RFC 2119 works). I thought the document would be clearer with 2119 language here, but it should not be included if you aren't comfortable using it. Thanks, Spencer Spencer Dawkins wrote: ... 3. WebDAV extended MKCOL The WebDAV MKCOL request is extended to allow the inclusion of a request body. The request body is an XML document containing a single DAV:mkcol XML element as the root element. The Content-Type Spencer (minor): if I'm reading this paragraph correctly, I'd suggest "The request body is an XML document that MUST contain a single DAV:mkcol XML element as the root element" here - the last sentence in this paragraph makes me think the requirement is normative, but it doesn't look normative to 2119 scanners :-) ... -0.5 As far as I can tell, it is a myth that things can only be normative when using RFC 2119 keywords. As a matter of fact, RFC 2119 points out: 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. So I'd prefer document authors to be more conservative in using those terms... BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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@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
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)
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)
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: AD review of draft-zorn-radius-pkmv1-04.txt
Glen Zorn wrote: > But none of the Attributes mentioned in Appendix B have anything to do with > RADIUS security as I understand it. Can you explain? From the document: Appendix B includes a listing of complex attributes used within [RFC2865], [RFC2868], [RFC2869], [RFC3162], [RFC4818], and [RFC4675]. The discussion of these attributes includes reasons why a complex type is acceptable, or suggestions for how the attribute could have been defined to follow the RADIUS data model. The intent of Appendix B is to explain what is *wrong* about the use of complex attributes in previous RFCs. Alan DeKok. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: AD review of draft-zorn-radius-pkmv1-04.txt
Glen Zorn wrote: > Alan DeKok wrote: > ... It would have been preferable ... > To which I reply: > > So it seems that what you _really_ meant was "... well, screw 'em." I think there is a miscommunication here. Alan DeKok. ___ 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)
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)
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)
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)
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)
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)
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)
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
