Prague (ietf-68) t-shirt laundry mix-up.
Hi, I'm hoping to get in touch with an IETF-72 attendee who stayed at the conference hotel, who did laundry and included their blue prague ietf t-shirt size 2-xlarge and received back a size large instead. I have you're 2xl and you have my large, please contact me so we can exchange. :) Chris. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call for Comments on Legal Provisions Related to IETF Documents
As someone who always prefers the BSD license, I agree with Simon on #1 and #2. Saying BSD except... means it is a new type of license, one that typical implementers will not expect. One way to look at this is to consider what happens if someone treats this as a real BSD license and doesn't give attribution. Is the IETF Trust really going to sue them over the lack of attribution? If not, why even have that addition to the BSD license? Like in our technical protocols, simplicity is good here. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Failing of IPR Filing Page when makling updates in re LTANS and other filings.
Folks - I found several working flaws with the IPR disclosure page when I went back to the IPR201 filing this AM to add several additional Internet Draft's for notice of Patent Controls; As to the IPR Page - it does not allow for updates of already filed IPR Statement's to include new IETF documents which violate the patent rights after the posting of the IPR Notice. So then how does one add more IETF infringing document's to an existing IPR declaration. That said we wanted to add several more document's which infringe on the patent protected IP's which we have refused to grant any rights to the IETF for. Those new additional documents include the latest LTANS DSSC (draft-ietf-ltans-dssc-03) document and to some extent Donald Eastlakes XML Signature RFC from 2002 (rfc3275) Luckily our patent filing predates ANY work on the XML signing document here in the IETF and for that matter in the W3C as well meaning lots of good things regarding that patent and its infringers. --- Personal Disclaimers Apply TS Glassey ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Failing of IPR Filing Page when makling updates in re LTANS and other filings.
On 8/12/08 12:02 PM, TS Glassey allegedly wrote: As to the IPR Page - it does not allow for updates of already filed IPR Statement's to include new IETF documents which violate the patent rights after the posting of the IPR Notice. How can a description of how to use a technology infringe on a patent? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Failing of IPR Filing Page when makling updates in re LTANS andother filings.
Scott Brim asked: How can a description of how to use a technology infringe on a patent? It can't. :-) But neither does IETF have any responsibility to parse and evaluate any of the frivolous claims made in IPR disclosures. Responding to loose IPR claims in public here only gives them undeserved credence. People and companies will file what IPR disclosures they will; other people will evaluate their importance when it becomes important to do so. /Larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Brim Sent: Tuesday, August 12, 2008 9:36 AM To: TS Glassey Cc: Contreras, Jorge; [EMAIL PROTECTED]; Carl Wallace; [EMAIL PROTECTED]; IETF Discussion Subject: Re: Failing of IPR Filing Page when makling updates in re LTANS andother filings. On 8/12/08 12:02 PM, TS Glassey allegedly wrote: As to the IPR Page - it does not allow for updates of already filed IPR Statement's to include new IETF documents which violate the patent rights after the posting of the IPR Notice. How can a description of how to use a technology infringe on a patent? ___ 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: Last Call for Comments on Legal Provisions Related to IETF Documents
NEW DOCUMENT Dated 8-12-08 This is to announce that the IETF Trustees have just posted a revised version of a draft policy on Legal Provisions Related to IETF Documents dated 08-12-08 at: http://trustee.ietf.org/policyandprocedures.html There is also a Comparison document and a separate Code Components List. Below is a summary of the changes and an explanation of them. On behalf of the IETF Trustees, we invite your review and final comments and suggestions on this policy. Given these changes, the Trustees will meet via telechat on September 4th with the goal of finalizing this policy. If you have any final comments, please post them on the IPR WG mailing list. Thanks Ray Pelletier IAD Trustee Summary of Changes 1. Intro -- changed this document to these Legal Provisions throughout the document. 2. Applicability -- moved Section 4 up to Section 2 for better flow. 2.a Effective Date -- Inserted a specific date for the effectiveness of the document, as discussed in Dublin. 2.b Effectiveness -- the Legal Provisions apply to IETF Contributions that are submitted after effectiveness, and to IETF Documents that are published after effectiveness. 3.a and 3.c Licenses -- the licenses now apply to IETF Contributions and IETF Documents in most places 3.c and 4.c Code -- clarified that Code included in IETF Documents can be reproduced and modified per the document licenses, while Code intended for execution is covered by the BSD License under Section 4. 3.c.iii.y Substantial Portion -- I was not sure whether there was consensus regarding the amount of text that could be extracted without applying the full RFC text/legends. 3.d Licenses Not Granted -- removed reference to disallowance of publishing I-Ds outside the IETF Standards Process. 3.f Termination -- deleted, per Dublin discussion 4.a Code Definition -- moved list of common code components to a URL 4.c Copyright notice -- changed notice in BSD license to reflect that this license now covers code from all IETF Contributions and Documents, not only RFCs. 4.d Attribution -- added a clause requiring identification of the relevant IETF Document/Contribution, per Dublin discussion. 6 Required Text -- added on the first page per Dublin discussion. 6.b Copyright Notice -- moved up from 6.c for improved flow. Also tweaked the text of the copyright notice to be more flexible, IETF Trust and the persons identified as its authors 7.e Definitive Version -- added a sentence to address the point about translations of these Legal Provisions. Ed Juskevicius wrote: This is to announce that the IETF Trustees have just posted a revised version of a draft policy on Legal Provisions Related to IETF Documents dated 08-05-08 at: http://trustee.ietf.org/policyandprocedures.html This draft includes all of the changes agreed during the July 31st meeting of the IPR working group held in Dublin. On behalf of the IETF Trustees, we invite your review and final comments and suggestions on this policy. The IETF Trustees will meet via telechat on Aug 21st with the goal of finalizing this policy. If you have any final comments, please post them on the IPR WG mailing list. Best Regards, and Thanks in advance, Ed Juskevicius Ray Pelletier Chair Trustee IETF Trust IETF Administrative Director ___ Ipr-wg mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/ipr-wg ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Failing of IPR Filing Page when makling updates in re LTANS andother filings.
On Tue, 12 Aug 2008, Lawrence Rosen wrote: Scott Brim asked: How can a description of how to use a technology infringe on a patent? It can't. :-) This isn't an entirely accurate and I'm always worried about inaccurate assertions from a lawyer. I think that one must be completely forthright about the possibilities. While I agree with Atty Rosen's position and I hope it will prevail, I have run into lawyers who assert that source code distribution does infringe a patent. There is no case law that I know of to back that up on patents and source code, but recent copyright cases have taken a very broad view of what constitutes copyright infringement, and this might signal a broader view on what constitutes patent infringement. The IETF must consider indirect infringement, where one merely encourages others to infringe, and contributory infringement, where the only use of a non-infringing device or method is to infringe a patent. I think the correct answer here is An IETF could possibly infringe on a patent. But neither does IETF have any responsibility to parse and evaluate any of the frivolous claims made in IPR disclosures. Responding to loose IPR claims in public here only gives them undeserved credence. People and companies will file what IPR disclosures they will; other people will evaluate their importance when it becomes important to do so. I don't know what a loose IPR claim is. However, it seems incumbent on the WG chairs and the IESG to evaluate the IPR claims made IPR disclosures to the same extent as anyone else. The WG Chairs and the IESG have a duty of due diligence to ensure that IETF documents don't indirectly infringe on patents nor engage in contributory infringement. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call for Comments on Legal Provisions Related to IETF Documents
How about adding some weasel words, or even simply making the attribution requirement a should? I think it's perfectly reasonable to ask for attribution when possible, so any form of words that doesn't break the BSD license in a narrow legalistic sense would do fine for me. It's not like we're asking for much: # This code was derived from IETF RFC . Please retain this comment if possible. Brian On 2008-08-13 03:07, Paul Hoffman wrote: As someone who always prefers the BSD license, I agree with Simon on #1 and #2. Saying BSD except... means it is a new type of license, one that typical implementers will not expect. One way to look at this is to consider what happens if someone treats this as a real BSD license and doesn't give attribution. Is the IETF Trust really going to sue them over the lack of attribution? If not, why even have that addition to the BSD license? Like in our technical protocols, simplicity is good here. --Paul Hoffman, Director --VPN Consortium ___ 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: Call for review of proposed update to ID-Checklist
I am working on a solution for this with the Secretariat. It is one aspect of the web site redesign project. I do not think that an Internet-Draft is needed. Russ At 11:40 AM 8/9/2008, Bert Wijnen \(IETF\) wrote: (1) Archive older versions in a plain text format as forI-Ds (for use with various IETF tools working on I-Ds) I can generate I-Ds if that helps. I can even submit those. Russ, do you want me to do that? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call for Comments on Legal Provisions Related to IETF Documents
At 9:33 AM +1200 8/13/08, Brian E Carpenter wrote: How about adding some weasel words, or even simply making the attribution requirement a should? I think it's perfectly reasonable to ask for attribution when possible, so any form of words that doesn't break the BSD license in a narrow legalistic sense would do fine for me. It's not like we're asking for much: # This code was derived from IETF RFC . Please retain this comment if possible. I would prefer a request to weasel words because it would be clearer. Please give attribution of the source of the code in the code itself, such as This code was derived from IETF RFC . --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call for Comments on Legal Provisions Related to IETFDocuments
Brian E Carpenter wrote: How about adding some weasel words, or even simply making the attribution requirement a should? I tend to forget the details, but IIRC we have a SHOULD for an attribution elsewhere (not in the part about code). If that is very clear folks might arrive at the conclusion that it's also *desired* for code snippets. But not *required*. It's not like we're asking for much: # This code was derived from IETF RFC . Please retain this comment if possible. Not fair. We can't put code with similar statements in an RFC in some cases, where somebody also didn't ask for much, just a beerware licence or copyright note or similar. Therefore we should also not ask for much from others if there's a chance that this is too much. Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Russ Housley wrote: I do not think that an Internet-Draft is needed. The source is already a variant of xml2rfc input, from there it's easy to arrive at plain text output for the ordinary diff tools. Adding version numbers for archiving working with the diff tool could be as simple as use name-NN.txt for version NN. Frank Russ At 11:40 AM 8/9/2008, Bert Wijnen \(IETF\) wrote: (1) Archive older versions in a plain text format as forI-Ds (for use with various IETF tools working on I-Ds) I can generate I-Ds if that helps. I can even submit those. Russ, do you want me to do that? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-tcpm-tcp-soft-errors (TCP's Reaction to Soft Errors) to Informational RFC
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP's Reaction to Soft Errors ' draft-ietf-tcpm-tcp-soft-errors-08.txt as an Informational RFC This is the second IETF last call for this document, to give the IPv6 community sufficient time to review how this document interacts with dual-stack hosts. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-08-26. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-soft-errors-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14290rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce