Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem
- Original Message - From: Bill Fenner fen...@fenron.com To: Tom.Petch sisyp...@dial.pipex.com Cc: Russ Housley hous...@vigilsec.com; trust...@ietf.org; ietf@ietf.org Sent: Wednesday, January 14, 2009 7:35 PM Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem On Wed, Jan 14, 2009 at 1:41 AM, Tom.Petch sisyp...@dial.pipex.com wrote: Ed's original announcement also placed significance on 0100 UTC on 16th December appearing to allow a grace period up until then during which 5378 was not in effect, since old boiler plate was acceptable. This is not quite accurate. RFC 5378 became BCP 78 at the time of publication on November 11th; even the old text says This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. So if you published an I-D with those words in it after RFC 5378 was published as BCP 78, then that I-D is subject to the rights, licenses and restrictions contained in RFC 5378. Thanks for the correction. I also had in mind contributions to mailing lists where the Note Well - eg the one sent out to this list on 1 January 2009 - references RFC5378 (or not as is the case in other settings) rather than BCP78. I am unclear whether this is by design or whether it is something that has yet to be brought in line with current thinking. Isn't it complicated? Tom Petch Bill ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
- Original Message - From: Andrew Sullivan a...@shinkuro.com To: ietf@ietf.org Sent: Thursday, January 15, 2009 4:52 AM Subject: Re: RFC 5378 contributions On Wed, Jan 14, 2009 at 08:33:35PM -0500, Contreras, Jorge wrote: No, absolutely not.nbsp; Use of pre-5378 materials in the IETF standards process has never been an issue, only use outside the IETF is problematic (ie, allowed under 5378 but not the earlier rules). Why is the actual situation of the use relevant? Because when an I-D is submitted, the submitter is confirming by the boiler plates included in the I-D, that they have gotten the relevant permissions to allow the IETF Trust to exercise the greater powers that RFC5378 gives them. So my take is that any substantial Contribution (as defined) must have the necessary permissions. Post November 9th Contributions of any kind were under the new rules, even if you had yet to be told so. Tom Petch Contribution is defined in section 1a of RFC 5378, and it plainly says that mailing list posting and anything one says at the microphone in any meeting is included in the definition. In section 5.1, RFC 5378 says that, by submitting the Contribution, the Contributor is deemed to have agreed that he/she has obtained the necessary permissions to enter into the agreement allowing the IETF to use the Contribution according to the new rules. So, just because the Contribution doesn't _happen_ to end up in use outside the IETF by virtue of the IETF's actions does not mean that a Contributor doesn't have to obtain the rights to allow such re-use. I believe that the _intent_ of 5378 is as you say, but the way it is written does not seem to restrict it in the way you say it does, at least when I read it as plain English prose. I'm not qualified to say whether there are other relevant legal considerations. Whether there is any practical effect to this state of affairs is quite another matter, too, of course. I find it hard to believe that there'd be a practical consequence; but then, I have found several actual legal decisions of the past to be hard to believe, too. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ 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: RFC 5378 contributions
Paul Hoffman wrote: At 1:38 PM +1300 1/15/09, Brian E Carpenter wrote: IANAL, but it seems to me that we should proceed on the assumption that this would fall under fair use provisions. Anything else would seem unreasonable to me. IANAL, and I'm only following about 10% of this thread, but the phrase fair use does not appear in RFC 5378. Maybe it should. Fair use is a concept of US law. 5378 tried to use language with reasonably global definitions. At one point it was suggested that RFC 5377 (desires for outgoing rights) should refer to fair use, but section 4.1 ended up saying that we want to grant unlimited permission to quote instead. Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
I'm happy with the answer re. use of pre-5378 RFC material on an IETF mailing list. I'm not sure about the answer re. use in an Internet-Draft. With respect to this, I think what Randy wanted to ask is: Do we need to get contributor premission before using material from an email posting made under pre-5378 Note Well in an Internet Draft with the full RFC 5378 boiler plate? Regards,Martin. At 10:33 09/01/15, Contreras, Jorge wrote: Content-class: urn:content-classes:message Content-Type: text/html;charset=utf-8 No, absolutely not. Use of pre-5378 materials in the IETF standards process has never been an issue, only use outside the IETF is problematic (ie, allowed under 5378 but not the earlier rules). - Original Message - From: ietf-boun...@ietf.org ietf-boun...@ietf.org To: IETF Discussion ietf@ietf.org Sent: Wed Jan 14 19:32:27 2009 Subject: RFC 5378 contributions Hi - I originally asked this question on the WG chairs' list, and was asked to ask again here... The discussion about RFC 5378 (what little I've been able to understand of it, anyway) has focussed on I-Ds and RFCs. However, the definition of contribution in that document includes, among other things, mailing list discussions. Does this mean that we need to get contributor permission before using, for example, material from a pre-5378 RFC in a mailing list discussion, or before including text from a pre-5378 email posting in an internet draft? This seems really silly, but that's what the discussion is starting to sound like to me. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietfhttps://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
I have to agree with Andrew and Tom. If someone stood up in a WG prior to whenever 5378 was effective* and made a suggestion of some length, or made a lengthy textual suggestion on a mailing list, and I copied that suggestion into a draft without any paraphrasing, a plain-sense reading of 5378's definition of Contributor means that I have to go back, find that person, and get permission to post that draft today (without a disclaimer), just because, in making the posting, I'm asserting that rights are in place that were not granted when the Contribution was made. john * I've said this several times before, but neither common sense nor fairness permits the IETF to say RFC 5378 became effective when it was published the first week in November, therefore any comments, contributions or drafts that appeared after that date constitute grants of permission under 5378's rules ... especially in the absence of any specific notice to that effect on relevant mailing lists, the presence of a Note Well in the IETF registration packet that referred to the old rules, etc. Those of us who trust that common sense interpretation (or who have been given legal advice that the odds of a judge accepting an early-November date contrary to that interpretation are fairly small) need to behave as if we cannot assume that Contributions made before late November or early December do not imply permission to use the Contributions under 5378 rules. --On Wednesday, January 14, 2009 22:52 -0500 Andrew Sullivan a...@shinkuro.com wrote: On Wed, Jan 14, 2009 at 08:33:35PM -0500, Contreras, Jorge wrote: No, absolutely not.nbsp; Use of pre-5378 materials in the IETF standards process has never been an issue, only use outside the IETF is problematic (ie, allowed under 5378 but not the earlier rules). Why is the actual situation of the use relevant? Contribution is defined in section 1a of RFC 5378, and it plainly says that mailing list posting and anything one says at the microphone in any meeting is included in the definition. In section 5.1, RFC 5378 says that, by submitting the Contribution, the Contributor is deemed to have agreed that he/she has obtained the necessary permissions to enter into the agreement allowing the IETF to use the Contribution according to the new rules. So, just because the Contribution doesn't _happen_ to end up in use outside the IETF by virtue of the IETF's actions does not mean that a Contributor doesn't have to obtain the rights to allow such re-use. I believe that the _intent_ of 5378 is ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
- Original Message - From: Russ Housley hous...@vigilsec.com To: Tom.Petch sisyp...@dial.pipex.com Sent: Wednesday, January 14, 2009 10:36 PM Correction: RFC 5378 was published on 10 November 2008. http://mailman.rfc-editor.org/pipermail/rfc-dist/2008-November/002142.html Thanks for the correction. I was about to point out that the latest draft licence from the IETF Trust refers in 5c to material published 'before November 10, 2008' but this now makes sense. ( In passing, the reference to November 12th was a mistake on my part; I was looking at Ed's announcement which spoke of the new rules coming in force 'today' and which my e-mail client tells me is November 12th. I should of course have looked at the e-mail headers and seen that he submitted the e-mail so as to generate 'Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C51A28C173; Tue, 11 Nov 2008 15:40:08 -0800 (PST)' which for GMT or places West is November 11th:-( Whatever, November 10th it is. What then is post-5378? Is it material published on or after November 10th? Tom Petch Russ At 11:20 AM 1/14/2009, Russ Housley wrote: Tom: RFC 5378 was published on 11 November 2008, and it went into effect on that date. Pre-5378 material refers to contributions that were made before the BCP went into effect. I do not believe that anyone tracked the posting time at a finer granularity than a day. Russ The At 04:41 AM 1/14/2009, Tom.Petch wrote: Russ I would like greater clarity about the meaning of pre-5378. Ed's original announcement said that the new regime was in effect from 12 November 2008 (no time specified). Ed's revised text uses 'before 10 November 2008' (no time specified). Ed's original announcement also placed significance on 0100 UTC on 16th December appearing to allow a grace period up until then during which 5378 was not in effect, since old boiler plate was acceptable. We appear to have four zones of time (up to 23:59:59 9th Nov, 10th/11th Nov, 12th Nov sometime to 00:00:59 UTC 16th December, thereafter). Please define, in a legally binding manner, pre- and post- 5378. After which, we may need transitional arrangements for people who posted in the middle two time zones, particularly for those who published in the first two weeks of December, thinking that they had a waiver and now find that they may have claimed rights in their Contribution that they will never possess (because it contains old text from earlier Contributions). snip ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
On Jan 15, 2009, at 7:09 AM, John C Klensin wrote: I have to agree with Andrew and Tom. If someone stood up in a WG prior to whenever 5378 was effective* and made a suggestion of some length, or made a lengthy textual suggestion on a mailing list, and I copied that suggestion into a draft without any paraphrasing, a plain-sense John, I am not a lawyer, you are (AFAIK) not a lawyer, and if the IETF counsel says otherwise, I would just let this one lie. The reason why I do not agree with this reasoning is that these rights are claimed through authorship. If I do not claim authorship in your draft because you use my text, when I have ample opportunity to do so, then I have (in my opinion) effectively lost them, especially in this context (where there is a note well, an assumption of joint contributions, etc.). In another context, I know that this is why songwriters can be so vociferous about getting their name as co-authors when a song is published - that is how they get royalties. Yes, I am sure that there are corner cases here, but one thing I have found about legal affairs is that there are always corner cases. No legal matter is ever sewn up 100%, and judges actually do take into consideration when things are done on advise of counsel. We have it, we should use it. Regards Marshall reading of 5378's definition of Contributor means that I have to go back, find that person, and get permission to post that draft today (without a disclaimer), just because, in making the posting, I'm asserting that rights are in place that were not granted when the Contribution was made. john * I've said this several times before, but neither common sense nor fairness permits the IETF to say RFC 5378 became effective when it was published the first week in November, therefore any comments, contributions or drafts that appeared after that date constitute grants of permission under 5378's rules ... especially in the absence of any specific notice to that effect on relevant mailing lists, the presence of a Note Well in the IETF registration packet that referred to the old rules, etc. Those of us who trust that common sense interpretation (or who have been given legal advice that the odds of a judge accepting an early-November date contrary to that interpretation are fairly small) need to behave as if we cannot assume that Contributions made before late November or early December do not imply permission to use the Contributions under 5378 rules. --On Wednesday, January 14, 2009 22:52 -0500 Andrew Sullivan a...@shinkuro.com wrote: On Wed, Jan 14, 2009 at 08:33:35PM -0500, Contreras, Jorge wrote: No, absolutely not.nbsp; Use of pre-5378 materials in the IETF standards process has never been an issue, only use outside the IETF is problematic (ie, allowed under 5378 but not the earlier rules). Why is the actual situation of the use relevant? Contribution is defined in section 1a of RFC 5378, and it plainly says that mailing list posting and anything one says at the microphone in any meeting is included in the definition. In section 5.1, RFC 5378 says that, by submitting the Contribution, the Contributor is deemed to have agreed that he/she has obtained the necessary permissions to enter into the agreement allowing the IETF to use the Contribution according to the new rules. So, just because the Contribution doesn't _happen_ to end up in use outside the IETF by virtue of the IETF's actions does not mean that a Contributor doesn't have to obtain the rights to allow such re-use. I believe that the _intent_ of 5378 is ... ___ 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: RFC 5378 contributions
On Thu, Jan 15, 2009 at 08:24:08AM -0500, Marshall Eubanks wrote: The reason why I do not agree with this reasoning is that these rights are claimed through authorship. That claim is precisely what I think is false, because RFC 5378 has defined Contributor in a particular way, and then asserted that there are certain terms to which Contributors are deemed to have agreed by virtue of making a Contribution. That a Contributor fails to assert some claim under those conditions seems irrelevant to me. That said, I completely agree that geeks playing at law is a nasty sight (I am tempted to think that it's how we got into this mess). I don't personally feel comfortable taking the say-so of the IETF Trust counsel, though, since the IETF Trust is an interested party in this discussion. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
On Thu, Jan 15, 2009 at 08:24:08AM -0500, Marshall Eubanks wrote: On Jan 15, 2009, at 7:09 AM, John C Klensin wrote: If someone stood up in a WG prior to whenever 5378 was effective* and made a suggestion of some length, or made a lengthy textual suggestion on a mailing list, and I copied that suggestion into a draft without any paraphrasing, a plain-sense John, I am not a lawyer, you are (AFAIK) not a lawyer, and if the IETF counsel says otherwise, I would just let this one lie. The reason why I do not agree with this reasoning is that these rights are claimed through authorship. If I do not claim authorship in your draft because you use my text, when I have ample opportunity to do so, then I have (in my opinion) effectively lost them, especially in this context (where there is a note well, an assumption of joint contributions, etc.). So it's a problem if every single I-D and RFC author is going to have to consult their own counsel before deciding that won't get into legal trouble when guaranteeing that all of their text is appropriately licensed. So whether or not I am I lawyer, and whether or not the Berne Convention very clearly states that copyright rights are automatically enforced, and do not need to be explicitly claimed, and whether or not the Note Well is enough to override the Berne Convention, John's position that he wants to be conservative enough not to make guarantees that might expose him to legal liability is a reasonable one. I don't think it's fair to say, I'm not a lawyer, and you're not a lawyer so you should do something which you fear exposes you to legal risk --- especially when all of the IP training many of us have gotten have basically told us that the Berne Convention explicitly states that you don't have to claim copyright to get copyright protections Yes, I am sure that there are corner cases here, but one thing I have found about legal affairs is that there are always corner cases. No legal matter is ever sewn up 100%, and judges actually do take into consideration when things are done on advise of counsel. We have it, we should use it. Has the IETF Counsel actually given explicit legal advice to all IETF contributors (which would have legal liability implications for the IETF Trust if said advice was wrong, as I understand things) that the Note Well to guarantee the transfer of RFC 5378 rights for text taken from IETF mailing list discussions or at an IETF meeting? Better yet would be if the IETF Trust was willing to ***indemnify*** I-D and RFC authors that they are on firm legal ground for asserting that they have all RFC 5378 rights when they take text from an IETF mailing list discussion or IETF face-to-face meeting, on the basis of the Note Well. After all, it is the IETF Trust which is requiring I-D and RFC authors to make this legal guarantee, so one might assert that in a fair world they should take the legal risks associated with that guarantee. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
More to the point, the question at hand was to what happens to mailing list discussions (or face to face discussions) which took place *before* RFC 5378 was published. John's observation was that it doesn't matter when the I-D or RFC is published, even if it is published *after* RFC 5378, if it contains text that was derived *before* RFC 5378, regardless of whether it came from an RFC, I-D, mailing list discussion, or face-to-face discussion, the RFC 5378 rights that a Contributor might provide wouldn't exist. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: RFC 5378 contributions
All -- It's been pointed out to me that I may have been answering the wrong question, or at least only a subset of the full question, in my posting of last night, so I'll clarify below in some detail. But first, for those whom I haven't met before, you should know that I'm a lawyer -- the lawyer who has been advising the Trust on these issues. I did help produce the work-around proposal that Ed circulated last week, and am also one of the co-authors of RFC 5378, so I take some of the blame for starting this whole mess in the first place. This being said, I'm not putting forward an official position of the Trust, nor has the below message been vetted by the Trust. It's simply my attempt to clarify my earlier response, which someone (not a Trustee) suggested that I send. 1. It's correct that Contribution, as defined in RFC 5378, includes e-mail exchanges, oral discussions and any other contribution to the IETF process. This definition has existed since RFC 3978 and the Note Well that has been published for the past several years. 5378 did not make a change here. 2. Therefor, the same rules that apply to I-D submission also apply to the other, less formal, types of contributions. John and others are correct in drawing this conclusion. 3. The IETF (meaning the collective activity of participants who interact on standards-development activities under the aegis of the IETF) has a perpetual, irrevocable right to use all Contributions in the IETF Standards Process. This right applies to all IETF Contributions, whether made under the rules in existence under 5378, 3978, 2026 or earlier. That was my response to Randy Presuhn last evening. 4. However, various people have identified a bug in 5378 that relates to hybrid Contributions -- those that contain both pre-5378 and post-5378 material. In short, contributors can't assure the Trust that pre-5378 contributions meet all the requirements of 5378. 5. The Trust's proposed work-around deals with this issue by allowing Contributors to flag hybrid contributions. If the flag is in place, then licenses outside the IETF Standards Process are not allowed, and the set of rights being granted for the pre-5378 and post-5378 material becomes equivalent (i.e., full use within the IETF Standards Process, plus a couple of other rights for code, etc.) As a result, if the flag is in place for a Contribution, the Contributor can make the warranties required by 5378 without worrying about any violation with respect to the included pre-5378 material. 6. While this flagging approach seems to be workable (from what I've heard) for I-Ds and other formal contributions, it would not be easy to manage for less formal contributions, such as e-mails and especially oral statements. That's the issue that John, Theodore and others have been elaborating recently, and I do agree. 7. Unfortunately, the Trust's ability to affect 5378 is limited to the inclusion (and tweaking) of the legends that are included in I-Ds and other written documents. 5378 does not give the Trust a broader power to alter the rights granted under 5378 or the warranties required by 5378. Thus, the proposed workaround, with the flag applied to submitted I-Ds, is probably as far as the Trust can go at this point (though I'm open to suggestions). 8. Ultimately, a fix is needed to 5378. But, in the interim, I was hoping that the proposed work-around would enable *most* IETF work to continue, and also hope that, while technically correct, the possibility of someone being sued for breaching a warranty with respect to an oral statement made at an IETF meeting is a very remote risk that would not inhibit IETF work. 9. This being said, I do agree that a permanent solution to fix 5378 is needed soon. This solution should address both formal and less formal types of Contributions, and, as Fred Baker and others have urged, require a minimum of effort on the part of IETF contributors. Thanks, Jorge Contreras -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John C Klensin Sent: Thursday, January 15, 2009 7:10 AM To: Andrew Sullivan; ietf@ietf.org Subject: Re: RFC 5378 contributions I have to agree with Andrew and Tom. If someone stood up in a WG prior to whenever 5378 was effective* and made a suggestion of some length, or made a lengthy textual suggestion on a mailing list, and I copied that suggestion into a draft without any paraphrasing, a plain-sense reading of 5378's definition of Contributor means that I have to go back, find that person, and get permission to post that draft today (without a disclaimer), just because, in making the posting, I'm asserting that rights are in place that were not granted when the Contribution was made. john * I've said this several times before, but neither common sense nor fairness permits the IETF to say RFC 5378 became effective when it was published the first week in
Re: Fourth Last Call: draft-housley-tls-authz-extns
Phil: For the people who want this draft published (and perhaps have a pending implementation), would you please humour me by offering some usage scenarios, other than debugging or toys, which would meet security review and which are not covered by the four points which the patent-holder notes as potentially encumbered? I'll offer one based on attribute certificates (see RFC 3281). If the attribute certificate policy does not use a critical certificate policy identifier that is within an arc registered to RedPhone Security (e.g. iso.org.dod.internet.private.enterprise.23106), then the most straightforward deployments would not encounter problems with this IPR Statement. RFC 3281 specifies ways to carry access identities, group memberships, roles, and clearances in attribute certificates. As long as these are not coupled to signed agreements such as contracts, as is their normal use, then I cannot see problems with this IPR statement. This is one example. I believe there are many more. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
IANAL, and I'm only following about 10% of this thread, but the phrase fair use does not appear in RFC 5378. Maybe it should. Fair use is specific to the U.S. Most other countries have similar legal concepts under other names like fair dealing, but they all differ in minor ways. This would run us into the swamp of what legal system we're subject to. I do have to say that this whole argument seems awfully hypothetical to me. No sensible person will ever sue for his text being reused from an RFC, non-sensible people will sue no matter what we do. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
On Jan 15, 2009, at 9:29 AM, Theodore Tso wrote: On Thu, Jan 15, 2009 at 08:24:08AM -0500, Marshall Eubanks wrote: On Jan 15, 2009, at 7:09 AM, John C Klensin wrote: If someone stood up in a WG prior to whenever 5378 was effective* and made a suggestion of some length, or made a lengthy textual suggestion on a mailing list, and I copied that suggestion into a draft without any paraphrasing, a plain-sense John, I am not a lawyer, you are (AFAIK) not a lawyer, and if the IETF counsel says otherwise, I would just let this one lie. The reason why I do not agree with this reasoning is that these rights are claimed through authorship. If I do not claim authorship in your draft because you use my text, when I have ample opportunity to do so, then I have (in my opinion) effectively lost them, especially in this context (where there is a note well, an assumption of joint contributions, etc.). So it's a problem if every single I-D and RFC author is going to have to consult their own counsel before deciding that won't get into legal trouble when guaranteeing that all of their text is appropriately licensed. This is an IETF list, to discuss matters of relevance to the IETF. Whether or not you need to consult counsel is not really on topic, and for sure you should not make that decision based on what anyone (especially me!) says on this list. If, on the other hand, you do obtain advice of counsel on this matter I would be curious to learn what they say. So whether or not I am I lawyer, and whether or not the Berne Convention very clearly states that copyright rights are automatically enforced, and do not need to be explicitly claimed, and whether or not the Note Well is enough to override the Berne Convention, John's position that he wants to be conservative enough not to make guarantees that might expose him to legal liability is a reasonable one. I don't think it's fair to say, I'm not a lawyer, and you're not a lawyer so you should do something which you fear exposes you to legal risk --- especially when all of the IP training many of us have gotten have basically told us that the Berne Convention explicitly states that you don't have to claim copyright to get copyright protections Yes, I am sure that there are corner cases here, but one thing I have found about legal affairs is that there are always corner cases. No legal matter is ever sewn up 100%, and judges actually do take into consideration when things are done on advise of counsel. We have it, we should use it. Has the IETF Counsel actually given explicit legal advice to all IETF contributors (which would have legal liability implications for the IETF Trust if said advice was wrong, as I understand things) that the Note Well to guarantee the transfer of RFC 5378 rights for text taken from IETF mailing list discussions or at an IETF meeting? Better yet would be if the IETF Trust was willing to ***indemnify*** I-D and RFC authors that they are on firm legal ground for asserting that they have all RFC 5378 rights when they take text from an IETF mailing list discussion or IETF face-to-face meeting, on the basis of the Note Well. After all, it is the IETF Trust which is requiring I-D and RFC authors to make this legal guarantee, so one might assert that in a fair world they should take the legal risks associated with that guarantee. Consider the threat model here. This threat applies ONLY to material that the Trust licenses to third parties (such as, say, the IEEE) for inclusion and modification in their standards. (Just reprinting or translating an RFC is not at issue.) Suppose that you author an RFC today, and use pre-5378 material, and warrant (in good faith) that the Trust has a license for that material, or apply a legend from the Trust that says that these rights are not obtainable by you, and it happens that the original author of that earlier material disagrees with this license to a third party. Note that these earlier author's (and their companies) agreed to freely use this material in the IETF process (the note well, etc.), and so you have no risk just by publishing the RFC as long as it is not licensed to other parties. The Trust would be the party that would be licensing this material to third parties, so clearly the Trust would be the major party at risk. What is your risk ? There is a theoretical risk that the Trust might sue you. That is one thing that the work-around is intended to remove. There is an actual risk that a third party might sue you and the Trust - specifically, that the original author or their heirs, etc., might sue. They can only do this if there is infringing use, and that would have to be based on a license from the Trust. If the Trust does NOT license your material to third parties, then there is no infringement, no one with standing to sue, and no risk to authors. It may be necessary for the Trust to state that they will not
Re: RFC 5378 contributions
Marshall Eubanks wrote: On Jan 15, 2009, at 9:29 AM, Theodore Tso wrote: On Thu, Jan 15, 2009 at 08:24:08AM -0500, Marshall Eubanks wrote: On Jan 15, 2009, at 7:09 AM, John C Klensin wrote: If someone stood up in a WG prior to whenever 5378 was effective* and made a suggestion of some length, or made a lengthy textual suggestion on a mailing list, and I copied that suggestion into a draft without any paraphrasing, a plain-sense John, I am not a lawyer, you are (AFAIK) not a lawyer, and if the IETF counsel says otherwise, I would just let this one lie. The reason why I do not agree with this reasoning is that these rights are claimed through authorship. If I do not claim authorship in your draft because you use my text, when I have ample opportunity to do so, then I have (in my opinion) effectively lost them, especially in this context (where there is a note well, an assumption of joint contributions, etc.). So it's a problem if every single I-D and RFC author is going to have to consult their own counsel before deciding that won't get into legal trouble when guaranteeing that all of their text is appropriately licensed. This is an IETF list, to discuss matters of relevance to the IETF. Whether or not you need to consult counsel is not really on topic, and for sure you should not make that decision based on what anyone (especially me!) says on this list. If, on the other hand, you do obtain advice of counsel on this matter I would be curious to learn what they say. So whether or not I am I lawyer, and whether or not the Berne Convention very clearly states that copyright rights are automatically enforced, and do not need to be explicitly claimed, and whether or not the Note Well is enough to override the Berne Convention, John's position that he wants to be conservative enough not to make guarantees that might expose him to legal liability is a reasonable one. I don't think it's fair to say, I'm not a lawyer, and you're not a lawyer so you should do something which you fear exposes you to legal risk --- especially when all of the IP training many of us have gotten have basically told us that the Berne Convention explicitly states that you don't have to claim copyright to get copyright protections Yes, I am sure that there are corner cases here, but one thing I have found about legal affairs is that there are always corner cases. No legal matter is ever sewn up 100%, and judges actually do take into consideration when things are done on advise of counsel. We have it, we should use it. Has the IETF Counsel actually given explicit legal advice to all IETF contributors (which would have legal liability implications for the IETF Trust if said advice was wrong, as I understand things) that the Note Well to guarantee the transfer of RFC 5378 rights for text taken from IETF mailing list discussions or at an IETF meeting? Better yet would be if the IETF Trust was willing to ***indemnify*** I-D and RFC authors that they are on firm legal ground for asserting that they have all RFC 5378 rights when they take text from an IETF mailing list discussion or IETF face-to-face meeting, on the basis of the Note Well. After all, it is the IETF Trust which is requiring I-D and RFC authors to make this legal guarantee, so one might assert that in a fair world they should take the legal risks associated with that guarantee. Consider the threat model here. This threat applies ONLY to material that the Trust licenses to third parties (such as, say, the IEEE) for inclusion and modification in their standards. (Just reprinting or translating an RFC is not at issue.) Suppose that you author an RFC today, and use pre-5378 material, and warrant (in good faith) that the Trust has a license for that material, or apply a legend from the Trust that says that these rights are not obtainable by you, and it happens that the original author of that earlier material disagrees with this license to a third party. Note that these earlier author's (and their companies) agreed to freely use this material in the IETF process (the note well, etc.), and so you have no risk just by publishing the RFC as long as it is not licensed to other parties. The Trust would be the party that would be licensing this material to third parties, so clearly the Trust would be the major party at risk. What is your risk ? There is a theoretical risk that the Trust might sue you. That is one thing that the work-around is intended to remove. There is an actual risk that a third party might sue you and the Trust - specifically, that the original author or their heirs, etc., might sue. They can only do this if there is infringing use, and that would have to be based on a license from the Trust. If the Trust does NOT license your material to third parties, then there is no infringement, no one with standing to sue, and no risk to authors. It may be necessary for the Trust to state that they will not assume
Re: Fourth Last Call: draft-housley-tls-authz-extns
Russ Housley hous...@vigilsec.com writes: Phil: For the people who want this draft published (and perhaps have a pending implementation), would you please humour me by offering some usage scenarios, other than debugging or toys, which would meet security review and which are not covered by the four points which the patent-holder notes as potentially encumbered? I'll offer one based on attribute certificates (see RFC 3281). If the attribute certificate policy does not use a critical certificate policy identifier that is within an arc registered to RedPhone Security (e.g. iso.org.dod.internet.private.enterprise.23106), then the most straightforward deployments would not encounter problems with this IPR Statement. RFC 3281 specifies ways to carry access identities, group memberships, roles, and clearances in attribute certificates. As long as these are not coupled to signed agreements such as contracts, as is their normal use, then I cannot see problems with this IPR statement. What's the point of a certificate if you don't ultimately couple it with a contract? Identities, group memberships, roles, and clearances are all attributes defined by non-technical, real-world agreements, often documented in the form of a contract. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
John C Klensin wrote: I have to agree with Andrew and Tom. If someone stood up in a WG prior to whenever 5378 was effective* and made a suggestion of some length, or made a lengthy textual suggestion on a mailing list, and I copied that suggestion into a draft without any paraphrasing, a plain-sense reading of 5378's definition of Contributor means that I have to go back, find that person, and get permission to post that draft today (without a disclaimer), just because, in making the posting, I'm asserting that rights are in place that were not granted when the Contribution was made. Correct. john * I've said this several times before, but neither common sense nor fairness permits the IETF to say RFC 5378 became effective when it was published the first week in November, therefore any comments, contributions or drafts that appeared after that date constitute grants of permission under 5378's rules ... especially in the absence of any specific notice to that effect on relevant mailing lists, the presence of a Note Well in the IETF registration packet that referred to the old rules, etc. Those of us who trust that common sense interpretation (or who have been given legal advice that the odds of a judge accepting an early-November date contrary to that interpretation are fairly small) need to behave as if we cannot assume that Contributions made before late November or early December do not imply permission to use the Contributions under 5378 rules. --On Wednesday, January 14, 2009 22:52 -0500 Andrew Sullivan a...@shinkuro.com wrote: On Wed, Jan 14, 2009 at 08:33:35PM -0500, Contreras, Jorge wrote: No, absolutely not.nbsp; Use of pre-5378 materials in the IETF standards process has never been an issue, only use outside the IETF is problematic (ie, allowed under 5378 but not the earlier rules). Why is the actual situation of the use relevant? Contribution is defined in section 1a of RFC 5378, and it plainly says that mailing list posting and anything one says at the microphone in any meeting is included in the definition. In section 5.1, RFC 5378 says that, by submitting the Contribution, the Contributor is deemed to have agreed that he/she has obtained the necessary permissions to enter into the agreement allowing the IETF to use the Contribution according to the new rules. So, just because the Contribution doesn't _happen_ to end up in use outside the IETF by virtue of the IETF's actions does not mean that a Contributor doesn't have to obtain the rights to allow such re-use. I believe that the _intent_ of 5378 is ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Internal Virus Database is out of date. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.4/1880 - Release Date: 1/7/2009 8:49 AM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
I had given my +1 a bit early after having seen the techniques for sending and receiving authorizations defined in TLS Authorizations Extensions (version draft-housley-tls-authz-extns-07.txt) do not infringe upon RedPhone Security's intellectual property rights Anyway, there are 4 points in the IPR claim that may require a license. The text is difficult to understand just by taking the text of the ID. The questions raised by others concerning the wording of the 4 points motivate me to step back. Peter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
Contreras, Jorge wrote: All -- It's been pointed out to me that I may have been answering the wrong question, or at least only a subset of the full question, in my posting of last night, so I'll clarify below in some detail. But first, for those whom I haven't met before, you should know that I'm a lawyer -- the lawyer who has been advising the Trust on these issues. I did help produce the work-around proposal that Ed circulated last week, and am also one of the co-authors of RFC 5378, so I take some of the blame for starting this whole mess in the first place. This being said, I'm not putting forward an official position of the Trust, nor has the below message been vetted by the Trust. It's simply my attempt to clarify my earlier response, which someone (not a Trustee) suggested that I send. 1. It's correct that Contribution, as defined in RFC 5378, includes e-mail exchanges, oral discussions and any other contribution to the IETF process. This definition has existed since RFC 3978 and the Note Well that has been published for the past several years. 5378 did not make a change here. Unfortunately that means that participation from anyone who's corporate policy is that the corporation owns the IP moving through their email gateway makes the individuals assertion of those rights subject to that oversight and as such the conveyance model is flawed and ineffective. 2. Therefor, the same rules that apply to I-D submission also apply to the other, less formal, types of contributions. John and others are correct in drawing this conclusion. yeah, but only because the IETF's process makes criminals out of those who fraudulently assert they have and continue to have power of attorney for their sponsors when in fact most all of them don't. 3. The IETF (meaning the collective activity of participants who interact on standards-development activities under the aegis of the IETF) has a perpetual, irrevocable right to use all Contributions in the IETF Standards Process. The scope of that changed and the actual terminology changed with these documents and since the IETF refused to force its submitters to prove that they actually do own those rights when 99% of the corporate sponsors have formally filed notices with their SOX compliance processes that there are no external contracts which effect their employees and no external contracts which effect their IP operations. This right applies to all IETF Contributions, whether made under the rules in existence under 5378, 3978, 2026 or earlier. That was my response to Randy Presuhn last evening. Hmmm... ONLY if the party submitting that IP has the legal authority to convey its ownership or to license it to the IETF. If the party working within the IETF doesnt have those rights then the IETF becomes a co-conspirator after the fact to a RICO violation one would think. 4. However, various people have identified a bug in 5378 that relates to hybrid Contributions -- those that contain both pre-5378 and post-5378 material. In short, contributors can't assure the Trust that pre-5378 contributions meet all the requirements of 5378. The same is true of revisions to existing documents when the submission conveyance process changed too. 5. The Trust's proposed work-around deals with this issue by allowing Contributors to flag hybrid contributions. If the flag is in place, then licenses outside the IETF Standards Process are not allowed, and the set of rights being granted for the pre-5378 and post-5378 material becomes equivalent (i.e., full use within the IETF Standards Process, plus a couple of other rights for code, etc.) As a result, if the flag is in place for a Contribution, the Contributor can make the warranties required by 5378 without worrying about any violation with respect to the included pre-5378 material. Again - this doesn't make sense to me. Pre-licensed works are still licensed under those terms whether the IETF changes those participation rules or not. 6. While this flagging approach seems to be workable (from what I've heard) for I-Ds and other formal contributions, it would not be easy to manage for less formal contributions, such as e-mails and especially oral statements. That's the issue that John, Theodore and others have been elaborating recently, and I do agree. 7. Unfortunately, the Trust's ability to affect 5378 is limited to the inclusion (and tweaking) of the legends that are included in I-Ds and other written documents. 5378 does not give the Trust a broader power to alter the rights granted under 5378 or the warranties required by 5378. Thus, the proposed workaround, with the flag applied to submitted I-Ds, is probably as far as the Trust can go at this point (though I'm open to suggestions). 8. Ultimately, a fix is needed to 5378. But, in the interim, I was hoping that the proposed work-around would enable *most* IETF work to continue, and also hope that, while technically correct, the
Re: Fourth Last Call: draft-housley-tls-authz-extns
Simon: For the people who want this draft published (and perhaps have a pending implementation), would you please humour me by offering some usage scenarios, other than debugging or toys, which would meet security review and which are not covered by the four points which the patent-holder notes as potentially encumbered? I'll offer one based on attribute certificates (see RFC 3281). If the attribute certificate policy does not use a critical certificate policy identifier that is within an arc registered to RedPhone Security (e.g. iso.org.dod.internet.private.enterprise.23106), then the most straightforward deployments would not encounter problems with this IPR Statement. RFC 3281 specifies ways to carry access identities, group memberships, roles, and clearances in attribute certificates. As long as these are not coupled to signed agreements such as contracts, as is their normal use, then I cannot see problems with this IPR statement. What's the point of a certificate if you don't ultimately couple it with a contract? Identities, group memberships, roles, and clearances are all attributes defined by non-technical, real-world agreements, often documented in the form of a contract. I can think of many that are not tied to contracts, especially in the manner described in the paragraph numbered 2 in the IPR statement. The authorization data needs to be used to locate the agreement. I've worked with many identification and authorization systems, and this is not a traditional aspect of any of them. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
Tom: What then is post-5378? Is it material published on or after November 10th? Yes. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
On Thu, Jan 15, 2009 at 11:50:46AM -0500, Marshall Eubanks wrote: Consider the threat model here. This threat applies ONLY to material that the Trust licenses to third parties (such as, say, the IEEE) for inclusion and modification in their standards. (Just reprinting or translating an RFC is not at issue.) So this licensing to third parties is not automatic; which makes sense in terms of letting the IESG to have a control point before allowing another standards body to take over a standard (or try to take over a standard). However, that presumably wouldn't be tree for allowing text or code to be used in implementations, open source or otherwise --- I assume that wouldn't require prior permission first, right? If the Trust does NOT license your material to third parties, then there is no infringement, no one with standing to sue, and no risk to authors. It may be necessary for the Trust to state that they will not assume 5378 to be in place for this purpose until there is a replacement. (In that case, if the IEEE or some other body wants to take over an RFC and modify it, they will have to get explicit permission from all authors until there is a replacement for 5378 in place, just as they did before 5378 as put into place.) My understanding is that the Trust is responsible for these licenses, and so they could just (in their best judgement) refuse to issue them without further conditions. So there probably isn't much risk for a standards bodies wanting to take over a MIB, for example, But what about someone using pseudo-code from a RFC where the RFC editor is required to make an assertion that he/she had all of the rights, and the code or pseudo code was contributed by a third party who copied the code from some Microsoft source they had access to while they were a graduate student? Or (and this is my opinion), maybe the authors should only warrant _their work_ as being subject to such licenses, and put the burden on the Trust to obtain any necessary approvals from other parties, only alerting the Trust to the extent they know of such prior authorship. My understanding is that this would require a 5378bis. That I think is the key; each person can only warrant what they themselves have authored. Something that might be worth looking at is the Developer's Certification of Origin, which is how Linux Kernel developers deal with contributions for the Linux Kernel. Anything which gets incoproated into the kernel must have a Signed-off-by, like this: Signed-off-by: Theodore Ts'o ty...@mit.edu What this mean is an explicit assertion of the following: Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. This would obviously have to be modified for the IETF's purpose, but what's nice about it is that each Linux Kernel Developer is only making assertions about things which he or she has personally has control over, and by using the Signed-off-by chain, it's possible to see the handoffs as the patch was passed up the chain from one developer to another, i.e: commit 166348dd37a4baacfb6fe495954b56f56b116f0c Author: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Date: Mon Sep 8 23:08:40 2008 -0400 ext4: Don't add the inode to journal handle until after the block is allocated Make sure we don't add the inode to the journal handle until after the block allocation, so that a journal commit will not include the inode in case of block allocation failure. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Signed-off-by: Mingming Cao c...@us.ibm.com Signed-off-by: Theodore Ts'o ty...@mit.edu - Ted ___ Ietf
Re: RFC 5378 contributions
Theodore Tso tytso at mit dot edu wrote: So it's a problem if every single I-D and RFC author is going to have to consult their own counsel before deciding that won't get into legal trouble when guaranteeing that all of their text is appropriately licensed. I certainly won't be volunteering to edit any more I-Ds after draft-ietf-ltru-4645bis if I have to worry about my personal legal liability if someone in the Working Group who contributed text has not granted me sufficient IP rights. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 166 messages in the last 7 days. script run at: Fri Jan 16 00:53:02 EST 2009 Messages | Bytes| Who +--++--+ 9.64% | 16 | 8.46% |98027 | john-i...@jck.com 7.23% | 12 | 6.00% |69483 | hous...@vigilsec.com 4.82% |8 | 6.79% |78668 | tglas...@earthlink.net 4.22% |7 | 6.52% |75480 | lro...@rosenlaw.com 4.82% |8 | 4.60% |53335 | brian.e.carpen...@gmail.com 3.61% |6 | 3.30% |38274 | ty...@mit.edu 3.01% |5 | 3.27% |37849 | t...@multicasttech.com 3.01% |5 | 2.64% |30537 | si...@josefsson.org 2.41% |4 | 2.34% |27156 | sisyp...@dial.pipex.com 2.41% |4 | 2.21% |25549 | i...@tonistoev.info 2.41% |4 | 2.02% |23417 | s...@resistor.net 2.41% |4 | 1.90% |22034 | randy_pres...@mindspring.com 1.81% |3 | 2.46% |28529 | do...@mail-abuse.org 2.41% |4 | 1.84% |21329 | d...@dcrocker.net 1.81% |3 | 2.22% |25669 | jorge.contre...@wilmerhale.com 1.81% |3 | 1.89% |21880 | bmann...@isi.edu 1.81% |3 | 1.81% |21015 | due...@it.aoyama.ac.jp 1.81% |3 | 1.60% |18490 | nar...@us.ibm.com 1.20% |2 | 2.03% |23459 | f...@cisco.com 1.20% |2 | 1.80% |20806 | m...@sendmail.com 1.20% |2 | 1.74% |20146 | har...@qualcomm.com 1.81% |3 | 1.09% |12612 | hartmans-i...@mit.edu 0.60% |1 | 2.19% |25361 | bernard_ab...@hotmail.com 1.20% |2 | 1.55% |17944 | edj@gmail.com 1.20% |2 | 1.16% |13489 | b...@estacado.net 1.20% |2 | 1.12% |12957 | j...@joelhalpern.com 1.20% |2 | 1.06% |12274 | s...@employees.org 1.20% |2 | 1.00% |11554 | ned+i...@mauve.mrochek.com 1.20% |2 | 0.92% |10662 | e...@networkresonance.com 1.20% |2 | 0.92% |10645 | j...@jlc.net 1.20% |2 | 0.87% |10031 | jari.ar...@piuha.net 1.20% |2 | 0.84% | 9739 | d...@ewellic.org 1.20% |2 | 0.84% | 9678 | m...@sandelman.ottawa.on.ca 1.20% |2 | 0.82% | 9479 | a...@shinkuro.com 1.20% |2 | 0.78% | 9089 | s...@cs.columbia.edu 1.20% |2 | 0.76% | 8754 | iab-ch...@ietf.org 1.20% |2 | 0.74% | 8555 | peter.sylves...@edelweb.fr 0.60% |1 | 1.24% |14416 | ramanch...@gmail.com 0.60% |1 | 1.24% |14314 | naim...@cisco.com 0.60% |1 | 1.13% |13048 | doug.mtv...@gmail.com 0.60% |1 | 0.86% | 9925 | denghu...@gmail.com 0.60% |1 | 0.80% | 9316 | sgo...@sipspectrum.com 0.60% |1 | 0.73% | 8471 | karl.vonwoot...@det.nsw.edu.au 0.60% |1 | 0.70% | 8138 | tim.p...@nist.gov 0.60% |1 | 0.70% | 8128 | ceastl...@att.com 0.60% |1 | 0.67% | 7793 | alexey.melni...@isode.com 0.60% |1 | 0.59% | 6848 | alia.at...@bt.com 0.60% |1 | 0.58% | 6667 | black_da...@emc.com 0.60% |1 | 0.54% | 6280 | ietf...@comcast.net 0.60% |1 | 0.54% | 6254 | jh...@cmu.edu 0.60% |1 | 0.51% | 5856 | ietf-spodh...@spodhuis.org 0.60% |1 | 0.51% | 5852 | sc...@kitterman.com 0.60% |1 | 0.50% | 5737 | amor...@amsl.com 0.60% |1 | 0.49% | 5664 | l...@cisco.com 0.60% |1 | 0.48% | 5614 | dcroc...@bbiw.net 0.60% |1 | 0.44% | 5121 | galvin+i...@elistx.com 0.60% |1 | 0.41% | 4804 | julian.resc...@gmx.de 0.60% |1 | 0.40% | 4619 | paul.hoff...@vpnc.org 0.60% |1 | 0.40% | 4594 | har...@alvestrand.no 0.60% |1 | 0.39% | 4478 | jo...@iecc.com 0.60% |1 | 0.38% | 4392 | fen...@fenron.com 0.60% |1 | 0.35% | 4074 | cas...@acm.org 0.60% |1 | 0.34% | 3988 | st...@stewe.org +--++--+ 100.00% | 166 |100.00% | 1158346 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
WG Action: Conclusion of Internet and Management Support for Storage (imss)
The Internet and Management Support for Storage (imss) working group in the Operations and Management Area has concluded. The IESG contact persons are Dan Romascanu and Ronald Bonica. The mailing list will remain open for discussions concerning implementations, questions and answers. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Performance Analysis of Inter-Domain Path Computation Methodologies' to Informational RFC
The IESG has approved the following document: - 'Performance Analysis of Inter-Domain Path Computation Methodologies ' draft-dasgupta-ccamp-path-comp-analysis-02.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dasgupta-ccamp-path-comp-analysis-02.txt Technical Summary This document presents a performance comparison between the per- domain path computation method and the Path Computation Element (PCE) Architecture based Backward Recursive Path Computation (BRPC) procedure. Metrics to capture the significant performance aspects are identified and detailed simulations are carried out on realistic scenarios. A performance analysis for each of the path computation methods is then undertaken. This may be thought of as *a* comparison that tried to capture some metrics. There is no attempt to draw a hard conclusion on which method to use Working Group Summary This purely informational document is an individual submission with AD sponsorship since it is not in the charter of either of the two most closely related WGs (CCAMP and PCE). However, the CCAMP and PCE working groups have been asked for comments, the document was updated based on comments received in CCAMP, and the IETF last call was forwarded to the CCAMP and PCE WGs to solicit their comments. Document Quality This document does not specify anything that would be implemented. The approaches that it is comparing are implemented and at least the MPLS-TE approach is widely deployed. Personnel Ross Callon is the AD sponsoring this individual submission. RFC Editor Note The section Requirements Language that introduces the standard key words (MUST, MUST NOT, and so on) can be dropped, since the document does not use these key words. Spelling virutal in section 2 should be virtual; Eventhough in section 4 should be Even though. Section 2 (Introduction). Please add the following paragraph to the end of this section: Note that this document contains multiple figures that are only available in the pdf version. Please delete both ietf-ccamp-lsp-stitching and ietf-ccamp-inter-domain-rsvp-te from the informative references. Please update the reference to draft-ietf-ccamp-inter-domain-pd- path-comp to instead reference RFC 5152. Please update the reference to draft-ietf-ccamp-inter-domain- rsvp-te to instead reference RFC 5151. Please update the reference to draft-ietf-ccamp-lsp-stitching to instead reference RFC 5150. Please update the reference to RFC 3784 to RFC 5305. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5410 on Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0
A new Request for Comments is now available in online RFC libraries. RFC 5410 Title: Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0 Author: A. Jerichow, Ed., L. Piron Status: Informational Date: January 2009 Mailbox:anja.jeric...@nsn.com, laurent.pi...@nagravision.com Pages: 7 Characters: 12444 Obsoletes: RFC4909 I-D Tag:draft-jerichow-msec-mikey-genext-oma-00.txt URL:http://www.rfc-editor.org/rfc/rfc5410.txt INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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
