Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
IETF Chair ch...@ietf.org writes: What does a contributor do in the situation when then want to build on an older work that was contributed prior to RFC 5378? In short, the contributor must obtain the additional rights from the original contributor. Doesn't that make it possible for copyright holders to make it difficult for the IETF to update older standards? Let's consider if company X participated as editor, or merely a major contributor, to document Y five years ago. Today competitor Z is critically dependent on this technology. Company X no longer builds products using Y technology. I could see how company X would not see any point in granting Z any rights to update the IETF standard in this situation. To update Y you will need to rewrite the entire document, to avoid copyright tainting. This seems like a serious problem with the new policy to me. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
IETF Chair ch...@ietf.org writes: SAM'S QUESTION What does a contributor do in the situation when then want to build on an older work that was contributed prior to RFC 5378? In short, the contributor must obtain the additional rights from the original contributor. To my knowledge, there has never been a requirement to document all copyright holders of material in documents approved under RFC 2026 or RFC 3978. There is wording that require all major contributors to be mentioned, but it seems possible that some part of a document is copyrightable but not be a major contribution. So, how would you actually know which old contributors to contact? Any what if the contributor is deceased? It would be very useful if the IAOC/Trust develop, together with legal aid, guiding instructions for this situation. It would answer the common questions. It seems applicable to a lot of work that will happen in the next 5 years: updating any RFC issues prior to RFC 5378. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Accountable Use Registry was: How I deal with (false positive) IP-address blacklists...
--On Thursday, 11 December, 2008 16:36 -0800 Douglas Otis do...@mail-abuse.org wrote: On Dec 11, 2008, at 1:51 PM, John C Klensin wrote: As soon as one starts talking about a registry of legitimate sources, one opens up the question of how ... Perhaps I should not have used the word legitimate. The concept of registry should engender a concept of accountability. ... Counter to this, much of the email abuse has been squelched by third-parties who allow network providers a means to indicate what traffic of which they are accountable. This is done in part by the assignment of address ranges as belonging to dynamically assigned users. It does seem as though a more formalized method though a registry support by provider fees would prove extremely beneficial at reducing the scale of the IP address range problem raised by IPv6. By formalizing a registration of accountable use, along with some type of reporting structure or clearinghouse, IPv6 would have a better chance of gaining acceptance. It would also empower providers to say what potentially abused uses they which to support. Again, while it is possibly that we are using different vocabularies or not communicating for other reasons, as soon as you say support by provider fees, I hear purchase a license to be able to send mail. I can imagine a number of organizations who would be happy to operate such a system and collect those fees. None of them make me very happy, especially if they are unregulated, and some would raise grave privacy concerns. ... A registry of accountable use in conjunction with some type of reporting structure seems a necessity if one hopes to ensure a player can obtain the access that they expect. In other words, not all things will be possible from just any IP address. Providers should first assure the Internet what they are willing to monitor for abuse, where trust can be established upon this promise. Not all providers will be making the same promise of stewardship. Those providers that provide the necessary stewardship for the desired use should find both greater acceptance and demand. Such demand may help avoid an inevitable race to the bottom. Doug, we've got a worked example of a system that was intended to provide protection against abuse by qualifying and certifying providers in return for a fee. The system was developed as the result of a consensus process among those who could convince others that they were stakeholders, not merely by a few providers making rules for others, so it should have been off to a good start. That system is ICANN's registrar accreditation process. It has been, IMO, effective at two things: (i) fattening ICANN's coffers and (ii) encouraging and developing a whole new industry of bottom-feeders, including many of those who contribute to the spam problem by supplying domain names to phishers and promoters of other kinds of fraud and helping to hide to ownership of those names. Unless you have a plausible theory about how a registration system can be run without falling victim to ICANN-like problems, I can't consider the idea very credible. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
On Dec 12, 2008, at 5:49 AM, Simon Josefsson wrote: IETF Chair ch...@ietf.org writes: SAM'S QUESTION What does a contributor do in the situation when then want to build on an older work that was contributed prior to RFC 5378? In short, the contributor must obtain the additional rights from the original contributor. To my knowledge, there has never been a requirement to document all copyright holders of material in documents approved under RFC 2026 or RFC 3978. There is wording that require all major contributors to be mentioned, but it seems possible that some part of a document is copyrightable but not be a major contribution. So, how would you actually know which old contributors to contact? One of my general principles is that engineers should not try to be lawyers, and I am dubious about any attempt to make IETF contributors obtain licenses from third parties. While this has been argued to death, here is what I propose : Contributors of IETF material should represent that one or more of 3 conditions apply to any particular contribution: 1.) There is no material in this contribution from pre-RFC5378 work. 2.) There is material in this contribution from pre-RFC5378 work by one or more of the current set of authors, and they hereby license this older material under the current conditions. 3.) There is material in this contribution from pre-RFC5378 work and the license status of that material may not be consistent with RFC5378. Number 3 is for the cases where the previous authors were different, or where the current authors do not own their previous work, and is in either case intended to flag the contribution as possibly one needing attention by the Trust. Note that # 2 and #3 are not mutually exclusive, and obviously the Trust Counsel would need to pass any actual wording. This would shift any work to obtain earlier licenses onto the Trust and the Trust Counsel, where in my opinion it belongs. This would also serve the useful purpose of automatically obtaining licenses from people who are just reusing their own work (if they are in a position to grant such a license). Regards Marshall Any what if the contributor is deceased? It would be very useful if the IAOC/Trust develop, together with legal aid, guiding instructions for this situation. It would answer the common questions. It seems applicable to a lot of work that will happen in the next 5 years: updating any RFC issues prior to RFC 5378. /Simon ___ 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: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
Marshall Eubanks t...@multicasttech.com writes: While this has been argued to death I disagree. The issue was raised only few weeks ago, and this e-mail thread is (as far as I have seen) the first where the problem has bee re-stated in an e-mail to any public IETF list. Contributors of IETF material should represent that one or more of 3 conditions apply to any particular contribution: 1.) There is no material in this contribution from pre-RFC5378 work. 2.) There is material in this contribution from pre-RFC5378 work by one or more of the current set of authors, and they hereby license this older material under the current conditions. 3.) There is material in this contribution from pre-RFC5378 work and the license status of that material may not be consistent with RFC5378. I like this. Number 3 is for the cases where the previous authors were different, or where the current authors do not own their previous work, and is in either case intended to flag the contribution as possibly one needing attention by the Trust. For # 3 it means that the Trust cannot sub-license it without contacting the original contributors. For all IETF internal purposes, there shouldn't be any problem. Note that # 2 and #3 are not mutually exclusive, and obviously the Trust Counsel would need to pass any actual wording. I believe even # 2 may need consideration by the trust, in case the pre-RFC5378 work contain copyrightable material written by others. This would shift any work to obtain earlier licenses onto the Trust and the Trust Counsel, where in my opinion it belongs. This would also serve the useful purpose of automatically obtaining licenses from people who are just reusing their own work (if they are in a position to grant such a license). Indeed. /Simon Regards Marshall Any what if the contributor is deceased? It would be very useful if the IAOC/Trust develop, together with legal aid, guiding instructions for this situation. It would answer the common questions. It seems applicable to a lot of work that will happen in the next 5 years: updating any RFC issues prior to RFC 5378. /Simon ___ 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: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
Let's do keep in mind that the license permission for reuse in IETF work has existed explicitly since RFC 2026 (1996) and implicitly for a long time before that. So, again for IETF work, the notion of having to either contact a lot of people to get permission or to completely rewrite is just not an issue, at least for documents that have been originated or revised since 1996. There is a gray area for code materials last published before 1996, but I suggest that they are few enough for the Trust to deal with on a special-case basis. That is, I assume, one of the reasons the IPR WG gave the Trust some flexibility. Given that, Marshall, your proposal essentially requires the Trust (and potentially Counsel) to do considerable work on behalf of hypothetical third parties who might want to make non-IETF use of some IETF materials. As someone who is getting very sensitive to the rapidly rising costs of IETF registration fees and other participation expenses, especially against the background of deteriorating economies, I see no reason why I, or any IETF participant who is not directly interested in the use of those materials for non-IETF purposes, should pay for that type of author-tracking-down and license-obtaining activity. I don't care how low that marginal cost is given volunteer time from Trustees and pro bono work from Counsel; if it adds only USD 10 to the meeting fees, it is far too much. If someone feels as need to reuse text that is not under the Trust's control, let them incur the expense. john p.s. I would not personally object to the Trust's imposing a hefty copyright licensing fee on anyone who wanted to use materials outside the IETF process, hefty enough to cover the costs of what you have proposed and leave a significant safety margin. But that would clearly be inconsistent with the intent of both the IPR WG generally and those who argued most strongly for the Trust to have these rights in particular. --On Friday, 12 December, 2008 08:51 -0500 Marshall Eubanks t...@multicasttech.com wrote: ... One of my general principles is that engineers should not try to be lawyers, and I am dubious about any attempt to make IETF contributors obtain licenses from third parties. ... This would shift any work to obtain earlier licenses onto the Trust and the Trust Counsel, where in my opinion it belongs. This would also serve the useful purpose of automatically obtaining licenses from people who are just reusing their own work (if they are in a position to grant such a license). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
Dear John; On Dec 12, 2008, at 10:10 AM, John C Klensin wrote: Let's do keep in mind that the license permission for reuse in IETF work has existed explicitly since RFC 2026 (1996) and implicitly for a long time before that. So, again for IETF work, the notion of having to either contact a lot of people to get permission or to completely rewrite is just not an issue, at least for documents that have been originated or revised since 1996. But isn't that what Russ's statement would impose ? As I read it, it puts the onus on the authors to obtain the additional rights from the original contributor. I think that in practice this requirement, if enacted, would lead to a lot of cosmetic rewriting of old text. There is a gray area for code materials last published before 1996, but I suggest that they are few enough for the Trust to deal with on a special-case basis. That is, I assume, one of the reasons the IPR WG gave the Trust some flexibility. Given that, Marshall, your proposal essentially requires the Trust (and potentially Counsel) to do considerable work on behalf of hypothetical third parties who might want to make non-IETF use of some IETF materials. Why ? I was trying to propose a means to alert the Trust to the potential of this work being required. If no one requests it, why do anything ? If they should, at least the Trust would have an idea as to whether or not they had these rights to give. As to whether the Trust should pay for this, or someone else, shouldn't that be determined on a case by case basis ? As someone who is getting very sensitive to the rapidly rising costs of IETF registration fees and other participation expenses, especially against the background of deteriorating economies, I see no reason why I, or any IETF participant who is not directly interested in the use of those materials for non-IETF purposes, should pay for that type of author-tracking-down and license-obtaining activity. I don't care how low that marginal cost is given volunteer time from Trustees and pro bono work from Counsel; if it adds only USD 10 to the meeting fees, it is far too much. If someone feels as need to reuse text that is not under the Trust's control, let them incur the expense. I agree with you in principle, but that seems orthogonal to the question of what the author's of current work should be doing. Regards Marshall john p.s. I would not personally object to the Trust's imposing a hefty copyright licensing fee on anyone who wanted to use materials outside the IETF process, hefty enough to cover the costs of what you have proposed and leave a significant safety margin. But that would clearly be inconsistent with the intent of both the IPR WG generally and those who argued most strongly for the Trust to have these rights in particular. --On Friday, 12 December, 2008 08:51 -0500 Marshall Eubanks t...@multicasttech.com wrote: ... One of my general principles is that engineers should not try to be lawyers, and I am dubious about any attempt to make IETF contributors obtain licenses from third parties. ... This would shift any work to obtain earlier licenses onto the Trust and the Trust Counsel, where in my opinion it belongs. This would also serve the useful purpose of automatically obtaining licenses from people who are just reusing their own work (if they are in a position to grant such a license). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
Let us be quite clear. The question of rights in pre-existing material is not a new question. It is inherent in any effort to increase the rights granted to the trust. While I can not assert what members of the WG or the community at last call understood, there is actually text in RFC 5377 that talks about the fact that there is a need to acquire suitable rights to older material. Given that the VAST majority of IETF work is work on existing documents, and given that authors and author's companies change frequently, if we do not insist that all work be under the new rules we will have essentially failed to increase the rights grant. As such, folks who use our material will not be able to make use of it in all the ways we intend. Hence, my personal conclusion is that for the trust to have arrived any any enforcement policy other than the one they did would have seemed to me to be a case of the trust contravening the stated intention of the IETF, as captured in the RFCs. Yours, Joel M. Halpern PS: TO be quite clear, the question of whether the enforcement date is December 12 2008, February 29, 2009, or April 1, 2009 is not a matter of meeting the IETF stated policy, but rather a question of the best way to meet that. The only reason I am not more concerned by the date is the fact that as a practical matter the bulk of I-D authors will actually have until late February to get the rights sorted out. Simon Josefsson wrote: Marshall Eubanks t...@multicasttech.com writes: While this has been argued to death I disagree. The issue was raised only few weeks ago, and this e-mail thread is (as far as I have seen) the first where the problem has bee re-stated in an e-mail to any public IETF list. Contributors of IETF material should represent that one or more of 3 conditions apply to any particular contribution: 1.) There is no material in this contribution from pre-RFC5378 work. 2.) There is material in this contribution from pre-RFC5378 work by one or more of the current set of authors, and they hereby license this older material under the current conditions. 3.) There is material in this contribution from pre-RFC5378 work and the license status of that material may not be consistent with RFC5378. I like this. Number 3 is for the cases where the previous authors were different, or where the current authors do not own their previous work, and is in either case intended to flag the contribution as possibly one needing attention by the Trust. For # 3 it means that the Trust cannot sub-license it without contacting the original contributors. For all IETF internal purposes, there shouldn't be any problem. Note that # 2 and #3 are not mutually exclusive, and obviously the Trust Counsel would need to pass any actual wording. I believe even # 2 may need consideration by the trust, in case the pre-RFC5378 work contain copyrightable material written by others. This would shift any work to obtain earlier licenses onto the Trust and the Trust Counsel, where in my opinion it belongs. This would also serve the useful purpose of automatically obtaining licenses from people who are just reusing their own work (if they are in a position to grant such a license). Indeed. /Simon Regards Marshall Any what if the contributor is deceased? It would be very useful if the IAOC/Trust develop, together with legal aid, guiding instructions for this situation. It would answer the common questions. It seems applicable to a lot of work that will happen in the next 5 years: updating any RFC issues prior to RFC 5378. /Simon ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
John C Klensin john-i...@jck.com writes: Let's do keep in mind that the license permission for reuse in IETF work has existed explicitly since RFC 2026 (1996) and implicitly for a long time before that. So, again for IETF work, the notion of having to either contact a lot of people to get permission or to completely rewrite is just not an issue, at least for documents that have been originated or revised since 1996. That conflicts sharply with how I read Russ' answer the contributor must obtain the additional rights from the original contributor. I wish you were right. I was surprised by the conclusion in the initial e-mail in this thread. I had believed all along that the IETF had sufficient rights to allow re-use of IETF documents within the IETF standard. I hope further explanation of the legal situation will give us more information. There is a gray area for code materials last published before 1996, but I suggest that they are few enough for the Trust to deal with on a special-case basis. That is, I assume, one of the reasons the IPR WG gave the Trust some flexibility. I don't see how this has anything to do with code vs text separation. The issue applies equally to code and text written before pre-RFC5378. There is nothing in Russ' note to suggest that this is related to only code, nor was this an aspect brought up by Sam. I listened to the recorded plenary a few days ago to remember the details. Given that, Marshall, your proposal essentially requires the Trust (and potentially Counsel) to do considerable work on behalf of hypothetical third parties who might want to make non-IETF use of some IETF materials. No. As far as I understand, I can no longer take RFC 4398, fix some minor problem, and re-submit it as a RFC 4398bis. Even though I was editor of RFC 4398. The reason is that some material in that document was written by others. At least, I cannot do this, without getting permission from the other people who wrote the initial document. I wish this is mistaken and that someone can explain how to reconcile this example with what Russ wrote. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Friday experiment
At Sat, 29 Nov 2008 13:15:23 +0100, Julian Reschke wrote: I think it would be good to finally enforce the rules for agenda submissions. For instance, if no agenda for a meeting is published in time, the meeting shouldn't take place. +1. I find it incredibly frustrating to be a week out from IETF and not know what drafts I need to read. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Friday experiment
Eric Rescorla allegedly wrote, On 12/12/08 2:26 PM: At Sat, 29 Nov 2008 13:15:23 +0100, Julian Reschke wrote: I think it would be good to finally enforce the rules for agenda submissions. For instance, if no agenda for a meeting is published in time, the meeting shouldn't take place. +1. I find it incredibly frustrating to be a week out from IETF and not know what drafts I need to read. They should be the ones that people have been arguing about for a month before that, so that it has become clear they need to be discussed in the meeting. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
On Dec 12, 2008, at 1:28 PM, Simon Josefsson wrote: John C Klensin john-i...@jck.com writes: Let's do keep in mind that the license permission for reuse in IETF work has existed explicitly since RFC 2026 (1996) and implicitly for a long time before that. So, again for IETF work, the notion of having to either contact a lot of people to get permission or to completely rewrite is just not an issue, at least for documents that have been originated or revised since 1996. That conflicts sharply with how I read Russ' answer the contributor must obtain the additional rights from the original contributor. I wish you were right. I was surprised by the conclusion in the initial e-mail in this thread. I had believed all along that the IETF had sufficient rights to allow re-use of IETF documents within the IETF standard. I hope further explanation of the legal situation will give us more information. My understanding (and IANAL and Jorge is welcome to correct me) is that the IETF does indeed have sufficient rights to allow re-use of IETF documents within the IETF, and that this is purely concerned with the power of granting modification rights to other parties. This is not a very common occurrence as far as I can tell, and so in some sense this is a corner case. Regards Marshall There is a gray area for code materials last published before 1996, but I suggest that they are few enough for the Trust to deal with on a special-case basis. That is, I assume, one of the reasons the IPR WG gave the Trust some flexibility. I don't see how this has anything to do with code vs text separation. The issue applies equally to code and text written before pre-RFC5378. There is nothing in Russ' note to suggest that this is related to only code, nor was this an aspect brought up by Sam. I listened to the recorded plenary a few days ago to remember the details. Given that, Marshall, your proposal essentially requires the Trust (and potentially Counsel) to do considerable work on behalf of hypothetical third parties who might want to make non-IETF use of some IETF materials. No. As far as I understand, I can no longer take RFC 4398, fix some minor problem, and re-submit it as a RFC 4398bis. Even though I was editor of RFC 4398. The reason is that some material in that document was written by others. At least, I cannot do this, without getting permission from the other people who wrote the initial document. I wish this is mistaken and that someone can explain how to reconcile this example with what Russ wrote. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
On Thu, Dec 11, 2008 at 3:40 PM, John C Klensin john-i...@jck.com wrote: ... the Trustees now believe that it is reasonable to [re] impose a deadline that gives the community two working days (it is already well into December 12 in much of the world) to modify and update tools to incorporate the new boilerplate. They gave one working day of notice that they expected the tools to be updated to begin accepting the new boilerplate last month, so this notification is at least twice as reasonable. Bill ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Friday experiment
At Fri, 12 Dec 2008 14:12:11 -0500, Scott Brim wrote: Eric Rescorla allegedly wrote, On 12/12/08 2:26 PM: At Sat, 29 Nov 2008 13:15:23 +0100, Julian Reschke wrote: I think it would be good to finally enforce the rules for agenda submissions. For instance, if no agenda for a meeting is published in time, the meeting shouldn't take place. +1. I find it incredibly frustrating to be a week out from IETF and not know what drafts I need to read. They should be the ones that people have been arguing about for a month before that, so that it has become clear they need to be discussed in the meeting. Perhaps so, but in most WGs I am involved in, plenty of new drafts show just before the meeting and people ask for discussion time, and then sometimes people don't show, so in practice trying to follow this algorithm gets you a very inaccurate list. Moreover, I (and others) use programmatic tools to extract the list of drafts to review and then go back and review the mailing list as necessary. So, all this works far better if the agenda is actually accurate. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
At 01:28 PM 12/12/2008, Simon Josefsson wrote: As far as I understand, I can no longer take RFC 4398, fix some minor problem, and re-submit it as a RFC 4398bis. Even though I was editor of RFC 4398. The reason is that some material in that document was written by others. At least, I cannot do this, without getting permission from the other people who wrote the initial document. I wish this is mistaken and that someone can explain how to reconcile this example with what Russ wrote. Correct. RFC 5378 imposes this burden on the contributor. All of the rights needed to make updates to the document within the IETF Standards Process are clearly already available, but the contributor is required to obtain the additional rights that are required by RFC 5378. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
Russ Housley hous...@vigilsec.com writes: At 01:28 PM 12/12/2008, Simon Josefsson wrote: As far as I understand, I can no longer take RFC 4398, fix some minor problem, and re-submit it as a RFC 4398bis. Even though I was editor of RFC 4398. The reason is that some material in that document was written by others. At least, I cannot do this, without getting permission from the other people who wrote the initial document. I wish this is mistaken and that someone can explain how to reconcile this example with what Russ wrote. Correct. RFC 5378 imposes this burden on the contributor. All of the rights needed to make updates to the document within the IETF Standards Process are clearly already available, but the contributor is required to obtain the additional rights that are required by RFC 5378. Interesting. Thanks for confirming the interpretation. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Time for a sign-up campaign [Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary]
I hereby extend the rights in my contributions that I have personally granted in the past to the IETF and to the IETF Trust to include the additional rights required by RFC5378. Obviously by doing so, I cannot extend the rights granted by my various employers. I'm going to print the updated license from http://trustee.ietf.org/authorlic.html and sign it and send it in. (My name is there because I signed the older version.) I'm disappointed at how few people have signed up. Even people who've been active in this debate haven't signed up to the old version. We should surely all be signing up to the new version, if we've ever made any kind of contribution in the past. We should all be pressing our employers to sign up. The problem that Sam raised will become a minor concern if the vast majority of us sign up. Brian Carpenter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
On 2008-12-12 12:40, John C Klensin wrote: ... So, given that, the Trustees now believe that it is reasonable to [re] impose a deadline that gives the community two working days (it is already well into December 12 in much of the world) to modify and update tools to incorporate the new boilerplate. On a purely practical note, http://xml.resource.org/experimental.html works just fine (thanks to Bill Fenner). Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
... the Trustees now believe that it is reasonable to [re] impose a deadline that gives the community two working days (it is already well into December 12 in much of the world) to modify and update tools to incorporate the new boilerplate. They gave one working day of notice that they expected the tools to be updated to begin accepting the new boilerplate last month, so this notification is at least twice as reasonable. I do not understand these comments. The Trustees are simply implementing the policy in RFC 5378 and the guidance given to them in RFC 5377. The only change to the boilerplate is the one that was already announced. The old boilerplate will no longer be accepted as of 16 December 2008, which is the same schedule that was announced earlier. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
Marshall: My understanding (and IANAL and Jorge is welcome to correct me) is that the IETF does indeed have sufficient rights to allow re-use of IETF documents within the IETF, and that this is purely concerned with the power of granting modification rights to other parties. This is not a very common occurrence as far as I can tell, and so in some sense this is a corner case. You are correct that the rights for the IETF Standards Process are already in place, at least for every contribution made after RFC 2026 was published. However, RFC 5378 does not include a provision for a contribution that does not grant all of the required rights. Even if the IETF Trust were to never make use of any rights beyond the IETF Standards Process, these additional rights must be granted under the requirements of RFC 5378. If a person cannot obtain the necessary rights, then that person cannot make a contribution to the IETF. This was the consensus of the IPR WG and the IETF, and the IETF is now operating under the resulting process BCP. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Time for a sign-up campaign [Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary]
At 8:56 AM +1300 12/13/08, Brian E Carpenter wrote: I'm disappointed at how few people have signed up. +1. The Trust even had cookies in the room when I signed my old form. New form is on the way to them. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
On 2008-12-13 08:20, Russ Housley wrote: At 01:28 PM 12/12/2008, Simon Josefsson wrote: As far as I understand, I can no longer take RFC 4398, fix some minor problem, and re-submit it as a RFC 4398bis. Even though I was editor of RFC 4398. The reason is that some material in that document was written by others. At least, I cannot do this, without getting permission from the other people who wrote the initial document. I wish this is mistaken and that someone can explain how to reconcile this example with what Russ wrote. Correct. RFC 5378 imposes this burden on the contributor. All of the rights needed to make updates to the document within the IETF Standards Process are clearly already available, but the contributor is required to obtain the additional rights that are required by RFC 5378. Formally yes. But the Trust can take the sting out of this by a vigorous effort to get former contributors to sign over the necessary rights, and by providing a convenient method for this to be done. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Time for a sign-up campaign [Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary]
I'm disappointed at how few people have signed up. Even people who've been active in this debate haven't signed up to the old version. I signed the old form (on paper) and handed it in a while back but do not see my name on the list -- did a bit get dropped somewhere? Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
A form is being developed to assist in this task. There is no requirement that the form be used, but it will be available shortly for anyone that chooses to make use of it. This form is now available. The Contributor non-exclusive license form has been updated to grant all of the rights required by RFC 5378. Anyone wishing to use the form can find it here: http://trustee.ietf.org/authorlic.html Your General Area Director, Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
Brian E Carpenter brian.e.carpen...@gmail.com writes: On 2008-12-13 08:20, Russ Housley wrote: At 01:28 PM 12/12/2008, Simon Josefsson wrote: As far as I understand, I can no longer take RFC 4398, fix some minor problem, and re-submit it as a RFC 4398bis. Even though I was editor of RFC 4398. The reason is that some material in that document was written by others. At least, I cannot do this, without getting permission from the other people who wrote the initial document. I wish this is mistaken and that someone can explain how to reconcile this example with what Russ wrote. Correct. RFC 5378 imposes this burden on the contributor. All of the rights needed to make updates to the document within the IETF Standards Process are clearly already available, but the contributor is required to obtain the additional rights that are required by RFC 5378. Formally yes. But the Trust can take the sting out of this by a vigorous effort to get former contributors to sign over the necessary rights, and by providing a convenient method for this to be done. Really? As far as I read the form in [1], it will give the IETF Trust the rights to your document. It does not give IETF participants any rights. And it is the IETF participants that will need to be able to grant the Trust these rights in order to submit a document, according to RFC 5378. What appears to be missing is a grant from the IETF Trust to IETF Participants for the documents signed over to them using the form. The legal provisions in [2] does not appear to provide this grant-back. It only grants rights to IETF participants to documents that are submitted after the effective date: The licenses granted by the IETF Trust pursuant to these Legal Provisions apply only with respect to (i) IETF Contributions (including Internet-Drafts) that are submitted to the IETF following the Effective Date, and (ii) IETF RFCs and other IETF Documents that are published after the Effective Date. Further: d. In most cases, rights to Pre-Existing IETF Documents that are not expressly granted under these RFCs can only be obtained by requesting such rights directly from the document authors. The IETF Trust and the Internet Society do not become involved in making such requests to document authors. /Simon [1] http://trustee.ietf.org/docs/Contributor_Non-Exclusive_License_RFC5378.pdf [2] http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Reserved IPv6 Interface Identifiers' to Proposed Standard
The IESG has approved the following document: - 'Reserved IPv6 Interface Identifiers ' draft-ietf-6man-reserved-iids-03.txt as a Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Jari Arkko and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6man-reserved-iids-03.txt Technical Summary Interface Identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet. Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them. An IPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences. Since there is no centralized repository for such reserved identifiers, this document aims to create one. Working Group Summary The 6MAN working group has done extensive reviews of this document and it reflects the consensus of the working group. Document Quality This document has been reviewed by numerous members of the i...@ietf.org mailing list and by the 6MAN WG chairs. Personnel Brian Haberman is the Document Shepherd, and Jari Arkko is the responsible Area Director. RFC Editor Note Make this change in Appendix A: OLD: The following RFCs that generate interface identifiers need to be updated if they wish to avoid conflicts with the reserved interface identifier ranges. NEW: Implementations of the following RFCs need to be aware of the reserved interface identifier ranges when they allocate new addresses. Future revisions of these RFCs should ensure that this is either already sufficiently clear or that the text is amended to take this into account. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
A form is being developed to assist in this task. There is no requirement that the form be used, but it will be available shortly for anyone that chooses to make use of it. This form is now available. The Contributor non-exclusive license form has been updated to grant all of the rights required by RFC 5378. Anyone wishing to use the form can find it here: http://trustee.ietf.org/authorlic.html Your General Area Director, Russ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5393 on Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies
A new Request for Comments is now available in online RFC libraries. RFC 5393 Title: Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies Author: R. Sparks, Ed., S. Lawrence, A. Hawrylyshen, B. Campen Status: Standards Track Date: December 2008 Mailbox:r...@nostrum.com, scott.lawre...@nortel.com, alan.i...@polyphase.ca, bcam...@estacado.net Pages: 20 Characters: 48722 Updates:RFC3261 I-D Tag:draft-ietf-sip-fork-loop-fix-08.txt URL:http://www.rfc-editor.org/rfc/rfc5393.txt This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
