Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns (fwd)
Forwarded on behalf of Dean. /Simon Dean Anderson [EMAIL PROTECTED] writes: Simon, could you please forward this to the IETF list for me? Thanks, --Dean -- Forwarded message -- Date: Fri, 27 Apr 2007 22:49:51 -0400 (EDT) From: Dean Anderson [EMAIL PROTECTED] To: Thierry Moreau [EMAIL PROTECTED] Cc: ietf@ietf.org, [EMAIL PROTECTED], Simon Josefsson [EMAIL PROTECTED], ietf@ietf.org, [EMAIL PROTECTED] Subject: RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns On Fri, 27 Apr 2007, Thierry Moreau wrote: Thus, look at the claims. Indeed, it needs training to read issued patent and patent applications, but that's the name of the game. The claims are important. But they aren't the only thing. The description of the invention (the specification) is a technical paper like any other, though nothing is left as an exercise for the reader. The specification and drawings are usually written by the inventor, perhaps with editing and prodding by a lawyer. The lawyer usually writes the claims. A small amount of legal background and terminology is sufficient to understand the claims---its a language that helps abstract the elements of the invention so that an infringement can be tested objectively against the claims. BTW, the patent examiner is usually not a lawyer, but a scientist. I don't see a logical relation between PAS functions and the patent application claims (it doesn't mean there isn't one). There isn't any relation beyond, 'A isn't patented, but B is'. RedPhoneSecurity is saying that if you don't do A, it will give you permission to do B (maybe for free for now, maybe not later). Of course, they want to make money somehow: probably they bet you'll want to do A if you do B according to their proposal, and they will be happy to sell you A. at that time. Of course, if this doesn't work out, the technology probably gets sold, and the new owner might not give our free licenses anymore. Business conditions can change. The ietf IPR disclosure 833 seems to be trying to force contractual obligations (assisting the enforcement of protected PAS functions) based on an assumed infringement threat which would induce some real/moral person to become a party to the contract (GUL). More or less, Yes. Though it isn't the disclosure that forces this. Its the patent in combination with the standard. They are using this to leverage to protect their PAS functions, which they obviously think have the real added value. They may be trying to patent the PAS functions, too, for all we know. Its hard to say, from our vantage point, what their interests are in the the deal. But they are interested in negotation to obtain a standard; it stands to reason, they expect to benefit. We can deduce some things. They will have a monopoly on the PAS functions by virtue of anyone who doesn't license the patent and agree not to implement the PAS functions, will be barred by the patent if they conform to the RFC--assuming we accept the RFC as is, of course. So one is in the position of either implementing non-standard behavior, or agreeing to non-competition with RedPhoneSecurity. That's quite an advantage for RedPhoneSecurity. That's probably worth a great deal of money, even. I'm always astonished to see ietf discussions about IPR so remote from simple IPR management basics. Yes. I looked at the specifics of the patent application, and specification as filed in the provisional application. Assuming the 5 independent claims are valid, You mean the 50 claims. There are 5 on the first page alone. I expect the patentholder would have great difficulty in establishing infringement against a source code maintainer organization for software maintenance and distribution activities. This is a gray area. I staked out a position on the openssl distribution years ago that source code is the same as the patent application itself---protected public information. The patent holder cannot prohibit the distribution of the patent documents. The holder cannot prohibit a book describing the invention. But the patent holder can prohibit anyone (except the government) from using their invention. They are under no obligation to license at all (IBM is well-known to patents stuff and sit on it--They invented RISC in the 70's and sat on it), and are also under no obligation to license fairly or reasonably. The 64million dollar question is whether a source code infringes. I can assure you that I have discussed the issue with very educated and prominent patent attorneys who think that a source code implementation [key word 'IMPLEMENTATION'] does infringe---plainly, using the source code infringes. You see the question: is source code an 'implementation' or a 'specification'? I say it is a specification: The patent specification also contains a sequence of steps just like a program
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Dear Mark: You volunteered extensive explanations about the specifics of your patent claims and licensing conditions per IPR disclosure 833. Thanks for doing so. There is no agreement or consensus to reach on these substantive questions, but your explanations may be useful to other participants in making their opinion on how the ietf standard drafting activities may proceed. Stated differently, I don't think you are negotiating licensing terms with the discussion forum: you state your best description of licensing terms in the IPR disclosure, and the ietf does its own thing, i.e. standards drafting activities. I doubt, however, that general principles (for standard drafting activities) can be easily inferred from the lessons of IPR disclosure 833, which is simply too complex! Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
John, On the one hand, let's just get started figuring out how the promise / request can be made so that it's not a burden to the open source community. I'm asking for input. Maybe a comment in the open-source source code (the way the EAY disclaimers read atop OpenSSL files for example) is sufficient to publicly request the GUL. Maybe that also satisfies the install disclosure as well, at least as far as the open source provider is concerned. I'm open to reasonable suggestions here. And I have benefited from Simon's pushback so far. My revised sense is that those who publish source code, such that promises embedded within that source code also get published, don't need to write a postcard. Those who are keeping their source code as a secret will need to notify RedPhone Security of their acceptance of the GUL more explicitly than in source code comments. On the other hand, I want to ask open source providers who accept the GUL to avoid knowingly trafficking in PAS Function implementations. Here's an analogy: PAS Function implementations aren't kiddie porn, but all the same they're not very compatible with public ftp sites, etc. In the analogy I mean this: In some countries, users of PAS Functions could/may be doing something illegal if that user doesn't have a license. I want to ask GUL-compliant open source publishers to discard contributions that implement PAS Functions, e.g. not roll them up into a release. This is my personal opinion of the GUL: IF person X, who doesn't participate in (or know about) the GUL makes a PAS Function, that's RedPhone Security's concern, not any open source provider's. If person X checks PAS Functions into a development/unstable source code tree operated by a GUL licensee, then I'd expect the GUL licensee to just delete that contribution when it's discovered, and not worry any further about it. In my mind, a scenario that violates the GUL would be where person X contributes (checks into source control), and a GUL licensee accepts the contribution, and that licensee functionally tests and approves the PAS Functions (thereby confirming that the contribution performs the PAS Functions described in the GUL), and then that licensee releases the PAS Functions as a stable / blessed build. That seems to me to be a three strikes and you're out GUL violation. In saying this, I'm trying to be flexible. I could go farther and try to work out more detailed scenarios that might reduce risk and burden, but I'd just be guessing. Instead, let me stop here and ask for input. Is there burden in putting a comment in source code that recites the RPS GUL, or is the burden in the postcard? I'm open to suggestions on the mechanics for making the GUL promise. Is it risky that a (possibly open source) software provider might accidentally but in good faith cruise through all three strikes with respect to the PAS functions (accept, test and release) and that their GUL might be void until things get patched up with RedPhone Security? Then let me know what risks are of concern so I can try to address them. To be fair, I can see that the open source community probably bears a higher burden to keep PAS Functions out of their source code, so I would like to try to ease the burden of requesting the GUL. So I'd like to work this out, but I will need some clear and direct feedback to get it right. Best regards, mark -Original Message- From: John C Klensin [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 11:23 AM To: Mark Brown; 'Simon Josefsson' Cc: [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED] Subject: RE: Withdrawal of Approval and Second Last Call: draft-housley- tls-authz-extns --On Monday, 23 April, 2007 17:17 -0500 Mark Brown [EMAIL PROTECTED] wrote: ... My understanding is this: The request for the GUL implies a promise not to implement the PAS Functions. This promise is valuable to RedPhone Security. If it's worth it to you to make the GUL promise (for whatever reasons, laws, or possibilities that you see) then you can make the promise and receive the GUL from RedPhone Security. Of course everyone is free to make their own decision about whether it's better to make the GUL promise or not. But if you don't make the promise, you won't get the GUL. ... Mark, with the usual IANAL qualifications, I've seen lots of general, you don't need to ask us licenses that contain this license is valid only as long as you refrain from doing the following things... language. The most common form of that language involves provisions about not suing the company granting the license, but that is by no means the only version. At least a few of the organizations that have written such licenses are very big players in the patent game. So, while reasonable people (and I assume lawyers :-( ) may disagree on how far it is necessary to go to get people to explicitly agree to those provisions, I infer that some organizations
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
John, I should have responded in my last email: I think you are being told --by a number of people and in different ways-- that there is a perception that having to ask for a license is seen as appreciably more burdensome and, for various reasons, risky than if a general license is granted without an application process. My impression is that is a general perception around the IETF, not just related to your work or proposal. So, rather than (or at least in addition to) telling others to go consult their lawyers to find out whether they could possibly work with your licensing requirements, I would encourage you to go back to your own and see if you can either (i) get the requirement to formally apply to you for a license removed or (ii) get a really good explanation as to why no strategy other than such an application is sufficient to meet your organizational needs. Sure, I can do that too. I'm a newcomer to the IETF, and sometimes I find myself a bit out of the loop regarding the general perception around the IETF. I appreciate you filling me in. --mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Hi Simon, It would be useful if you could explore with your lawyers if it is actually easy for you to avoid problem (1). I'm wondering what exactly the requirement for implementers to request this license from you gives you. Your text suggest that you will never refuse to grant the rights in your license to someone who ask, is that right? If so, what problem would there be in granting the rights immediately to everyone, without a need to request it from you? Is your reason that you want to know who is using your IPR, and open up a communication channel with them? To solve that concern, you could write a request that everyone is requested, but not legally required, to get in touch with you. That would get you into contact with the majority that is positive about talking with you, and you wouldn't need to hear from people who doesn't want to talk with you. My understanding is this: The request for the GUL implies a promise not to implement the PAS Functions. This promise is valuable to RedPhone Security. If it's worth it to you to make the GUL promise (for whatever reasons, laws, or possibilities that you see) then you can make the promise and receive the GUL from RedPhone Security. Of course everyone is free to make their own decision about whether it's better to make the GUL promise or not. But if you don't make the promise, you won't get the GUL. Replacing the need to request a license from you with a requirement to place a comment in header files to make things clear to end users may be acceptable, possibly barring the problem in the next paragraph. This is basically the same as giving the rights directly to everyone, without a need to contact you. So it seems you have already started leaning towards that solution. (It is important that you do not require that the comment is placed in all advertising material, or similar, or you will run into the problem that the original BSD license had with GPL-compatibility.) Making the GUL promise costs no money (that part is free); I hope it doesn't cost anybody any time to _not_ implement the PAS Functions; and I don't want to make the mechanics of making the request / promise cost a lot of time either. But the GUL promise as valuable consideration is the cost of the GUL to Manufacturers. As far as I can see, it's not ok to omit this. I hope many people find the offer attractive. As I mentioned, I'm open to suggestions and feedback on the mechanics of making the request. Another basic problem is that free software projects may not be able to agree to your field-of-use limitation in (2) and at the same time be compatible with license such as the GNU General Public License. Thus they would never be able to implement tls-authz even without any support for PAS under your license. I am not certain of this, but I could ask the Free Software Foundation's lawyers about this -- they are the copyright holder of GnuTLS which implements tls-authz without PAS today, and can speak authoritatively about this. I would appreciate if you would follow up with your lawyer(s) on this question. As I've said before, I believe that even if GNUTLS/FSF (for example) made the GUL promise, its software would continue to be free to use because only GNUTLS (or whatever parent organization) would be bound to honor that promise. I hope your lawyers will find this to be true. Best regards, mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns (fwd)
Forwarded on behalf of Dean. /Simon Dean Anderson [EMAIL PROTECTED] writes: Simon, could you please forward this to the IETF list. I suspect there are many people who don't know about the WIPO filing, or don't realize what it means for them. Thanks, --Dean -- Forwarded message -- Date: Thu, 19 Apr 2007 16:21:50 -0400 (EDT) From: Dean Anderson [EMAIL PROTECTED] To: Simon Josefsson [EMAIL PROTECTED] Cc: Mark Brown [EMAIL PROTECTED], [EMAIL PROTECTED], ietf@ietf.org, [EMAIL PROTECTED] Subject: Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns On Thu, 19 Apr 2007, Simon Josefsson wrote: Finally, here is another problem to consider: Your patent isn't valid in the entire world. This isn't exactly true. RedphoneSecurity has a WIPO patent filing. That gives them priority in every WIPO country, which is basically the civilized world. (184 member countries). http://www.wipo.int/members/en/ The patent is valid for priority in Sweden. Swedish residents will have to obtain a patent license. --Dean You will run into situations where a manufacture is not bound or affected by your license. Only end-users or re-distributors in some countries will be affected. I believe this is the case for GnuTLS, I developed the tls-authz functionality in Sweden and as far as I can tell your patent isn't valid here. I see no reason to request or agree with the GUL. You may want to offer a license not only to manufacturers, but to end-users or re-distributors. This makes the licensing situation much more complex. -- 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://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
--On Monday, 23 April, 2007 17:17 -0500 Mark Brown [EMAIL PROTECTED] wrote: ... My understanding is this: The request for the GUL implies a promise not to implement the PAS Functions. This promise is valuable to RedPhone Security. If it's worth it to you to make the GUL promise (for whatever reasons, laws, or possibilities that you see) then you can make the promise and receive the GUL from RedPhone Security. Of course everyone is free to make their own decision about whether it's better to make the GUL promise or not. But if you don't make the promise, you won't get the GUL. ... Mark, with the usual IANAL qualifications, I've seen lots of general, you don't need to ask us licenses that contain this license is valid only as long as you refrain from doing the following things... language. The most common form of that language involves provisions about not suing the company granting the license, but that is by no means the only version. At least a few of the organizations that have written such licenses are very big players in the patent game. So, while reasonable people (and I assume lawyers :-( ) may disagree on how far it is necessary to go to get people to explicitly agree to those provisions, I infer that some organizations who are probably not naive about these things have concluded that an application process is not necessary. Now I want to turn the logic of your note around. You and/or RedPhone Security have presumably concluded that you would derive some value from having the IETF publish this document, preferably on the standards track. I don't need to speculate as to where on the spectrum between altruism, a belief that it would enhance your reputation(s), or a belief that having this out there as an RFC would enhance your ability to market the PAS bits that you are not giving away to conclude that you see _some_ benefit to yourselves or the larger community: if you don't, the investments you have clearly made in this would be dumb and I have no reason to believe that you, your organization, or your lawyers are dumb. Without getting into a discussion about whether particular provisions are or are not usable by particular communities, I assume it is clear to everyone that, if an encumbered technology is proposed for standardization, the IETF's rules require making a decision as to whether or not the technology is important enough to justify accepting the encumbrances. For me, at least, that isn't a binary decision -- it involves weighing the level of encumbrances and/or aggravation in working around them against that perception of importance. I think you are being told --by a number of people and in different ways-- that there is a perception that having to ask for a license is seen as appreciably more burdensome and, for various reasons, risky than if a general license is granted without an application process. My impression is that is a general perception around the IETF, not just related to your work or proposal. So, rather than (or at least in addition to) telling others to go consult their lawyers to find out whether they could possibly work with your licensing requirements, I would encourage you to go back to your own and see if you can either (i) get the requirement to formally apply to you for a license removed or (ii) get a really good explanation as to why no strategy other than such an application is sufficient to meet your organizational needs. In my personal opinion, and given that experts in the relevant parts of the community are telling us that this technology is not critical to the most-important functions of TLS, if you can't or won't do that, the IETF should simply conclude that our interests in publication of this material are not sufficient to overcome the disadvantages of the encumbrances, stop spending time on this discussion, and move on. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Mark Brown [EMAIL PROTECTED] writes: However, if I understand the license correctly, it seems incompatible with free software licenses. The RedPhone license contains: 1. General Use License Upon request, RedPhone Security will provide a worldwide, nonexclusive, fully-paid, perpetual, royalty-free patent license to manufacturers who (a) implement the Protocol, (b) acknowledge this general use license as described in Schedule B, and (c) refrain from implementing any Protected Assurance System Functions defined and listed below. This general use license granted to manufacturers also flows down to sublicensees and users, to permit end users of these systems (including both client and server components) to use the Protocol, provided those users do not use the system as a Protected Assurance System (PAS) as defined in Schedule A without obtaining an End User License. There are two problems here: 1) Requires that vendors 'request' the license. It would be better if the license was given directly to third parties without any action required by the third parties. 2) The restriction of field-of-use (i.e., cannot be used with PAS) is incompatible with free software norms: implementations must be usable for any purpose as long as the license is followed, and several free software licenses does not permit restrictions like this. Problem 1 seems solvable to me, but I'd like more input. For 2, My goal is this exchange: Manufacturer: We're requesting the General Use License from RedPhone Security. In exchange, we promise not to implement (or on a per-release basis: we did not implement) the PAS Functions. Each Manufacturer needs to take responsibility only for his own actions; any subsequent Manufacturer (alters the code in a way that may or may not be material to the PAS Functions) either voids the license or inherits it or requests their own license -- but that's not your problem. A Manufacturer will develop code, test the functionality and release the software. At each of these steps it should be pretty clear if the software being developed, tested and released violates the PAS Functions. ..Doubly clear if the function of the software is to make use of X509 certificates which are marked with a critical policy that identifies RedPhone Security (a hard-coded OID ending in .23106 will likely show up in the software). I think a free software provider/clearinghouse could choose to not go beyond the RedPhone Security General Use License with no problem. In the event that some third party contributor made a code contribution back to the provider that violated the PAS Functions, simply classify that code-contribution as buggy -- and choose to not roll that contribution up into any release. I can imagine a case where a user of free software chooses to start with free software and then obtain a PAS License from RPS and become Manufacturer2. Then the score would be: Manufacturer1: GUL, Manufacturer2: PASL, and both would remain true to their commitments -- no problems. The only problem would be if Manufacturer2 contributed PAS Functions back to Manufacturer1 and then Manufacturer1 rolled those functions in (and tested and released them) under GUL. Back to question 1, I guess the question for me is, Who is making the promise to RedPhone Security? How the promise is communicated is not the main issue. If the preferred OpenSSL approach is to put a legal stuff into comments atop source files which are published for anyone to see, that may be more effective than sending one postcard. This may also help (somewhat) the on installation question. If one Manufacturer only releases (presumably tested) source code, then on installation for source code could simply be comments atop the source code file. What I want to accomplish is fair warning to downstream users / Manufacturers, so that we can help users steer clear of accidental GUL violations. In summary, for (1) I'd like more input. RPS will provide a GUL upon request, by snail mail or electronically. The question I have is how an open source provider might prefer to make that request with its associated promise about PAS Functions -- once and for all, or from time to time, etc. This question could be sorted out on a per-license basis, but I think consistency would be preferable. For (2) I'd like each Manufacturer/User to stand on his or her own two feet. If you made or used the PAS Functions, you need a license. Otherwise, say you didn't under the GUL. No Manufacturer under the GUL should be responsible for implementations of PAS Functions that they did not develop, test and/or release. Hi Mark! I believe I understand what you are trying to achieve here. It looks like a clean separation, but the problems are in the details. Below I'm speaking only from my point of view as a developer,
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
[EMAIL PROTECTED] writes: The authors asked for a week delay while they prepared a new IPR disclosure. That disclosure seems to have hit the IETF servers Ah, good. For easy reference, the new IPR disclosure is available from: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=833 From a proprietary perspective, it appears to be a rather permissive license. It seems to be one of the better ones that I have read relative to the other licenses in the IETF IPR disclosure list. Kudos to Mark! However, if I understand the license correctly, it seems incompatible with free software licenses. The RedPhone license contains: 1. General Use License Upon request, RedPhone Security will provide a worldwide, nonexclusive, fully-paid, perpetual, royalty-free patent license to manufacturers who (a) implement the Protocol, (b) acknowledge this general use license as described in Schedule B, and (c) refrain from implementing any Protected Assurance System Functions defined and listed below. This general use license granted to manufacturers also flows down to sublicensees and users, to permit end users of these systems (including both client and server components) to use the Protocol, provided those users do not use the system as a Protected Assurance System (PAS) as defined in Schedule A without obtaining an End User License. There are two problems here: 1) Requires that vendors 'request' the license. It would be better if the license was given directly to third parties without any action required by the third parties. 2) The restriction of field-of-use (i.e., cannot be used with PAS) is incompatible with free software norms: implementations must be usable for any purpose as long as the license is followed, and several free software licenses does not permit restrictions like this. Studying problem 2) in more detail for some common licenses: 1) Section 6 of the GPL and section 10 of the LGPL which says: You may not impose any further restrictions on the recipients' exercise of the rights granted herein. http://opensource.org/osi3.0/licenses/gpl-license.php http://opensource.org/osi3.0/licenses/lgpl-license.php 2) Section 2.1 of the Mozilla 1.1 License: The Initial Developer hereby grants You a world-wide, royalty-free, non-exclusive license, subject to third party intellectual property claims: ... (b) under Patents Claims infringed by the making, using or selling of Original Code, to make, have made, use, practice, sell, and offer for sale, and/or otherwise dispose of the Original Code (or portions thereof). http://opensource.org/osi3.0/licenses/mozilla1.1.php 3) Section 3 of the Apache 2.0 License: http://opensource.org/osi3.0/licenses/apache2.0.php I stopped looking at licenses after that, but I'm sure similar problems can be found with other licenses. These are licenses that widely adopted TLS implementations are distributed under. Thus, it seems that this license may allow some proprietary vendors to implement tls-authz, but it prevents free software vendors to provide a GPL/LGPL/Mozilla/Apache/etc implementation because the RedPhone license is incompatible with these free software licenses. I don't believe this was the intention. Mark, would you like to comment? I am inclined to believe that Mark's license is more consequence of lack of understanding how free software licensing works, rather than bad-faith against free software. Perhaps there is some use of an informational document that explains how IPR disclosures needs to be written in order to be free software friendly. Mark, others, would such a document be helpful when trying to write an IPR disclosure? At this point, I think I'm bringing up a generic concern which also affects many other drafts with IPR disclosures than Mark's. It is somewhat unfair to Mark to have to go through all these discussions because the IETF doesn't have fully functioning procedures and/or guidelines on this. Still, since this document is a good example of patented technology aiming at the standards track, with a license incompatible with free software licenses, and I believe the IETF should discuss the problem -- as a general problem, not just for Mark's document -- further. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Simon, Can you identify any instance of a non-profit GPL implementor or distributor being sued for not having sent a postcard for the style of RF license you are objecting to? Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Brian E Carpenter [EMAIL PROTECTED] writes: Simon, Can you identify any instance of a non-profit GPL implementor or distributor being sued for not having sent a postcard for the style of RF license you are objecting to? Brian, two responses: 1) You seem to assume that GPL implementers would violate the patent license by redistributing their code without sending a postcard. In order words, your question assumes and implies bad-faith amongst GPL implementers. What typically happens in practice, among good-faith practitioners, is that there won't be any GPL (or Apache, or Mozilla, or ...) implementation of the patented technology at all, because the necessary rights cannot be acquired. 1) I don't believe this is a 'send a postcard' license. If you read Mark's patent license, it starts with: Upon request, RedPhone Security will ... I interpret this to mean that unless RedPhone responds to your requests, you have not received any rights. Is this incorrect? There are examples where companies won't respond to requests for these type of RF patent licenses. A recent example that came to mind was related to the BOCU patent by IBM: http://permalink.gmane.org/gmane.text.unicode.devel/23256 A different problem is if the patent is owned by a small company, and the company goes away. Still, I'm not sure even a send-a-postcard patent license would be compatible with free software licenses. Sending the postcard appear to be an additional requirement, something that some free software licenses explicitly forbid. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Simon Josefsson [EMAIL PROTECTED] writes: There are examples where companies won't respond to requests for these type of RF patent licenses. A recent example that came to mind was related to the BOCU patent by IBM: http://permalink.gmane.org/gmane.text.unicode.devel/23256 A better URL is: http://thread.gmane.org/gmane.text.unicode.devel/22875/focus=22938 /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On 2007-04-11 10:08, Simon Josefsson wrote: Brian E Carpenter [EMAIL PROTECTED] writes: Simon, Can you identify any instance of a non-profit GPL implementor or distributor being sued for not having sent a postcard for the style of RF license you are objecting to? Brian, two responses: 1) You seem to assume that GPL implementers would violate the patent license by redistributing their code without sending a postcard. In order words, your question assumes and implies bad-faith amongst GPL implementers. Not specifically. My question is a practical one. People who receive open source code, tweak it, and install it may often be completely unaware that they should be asking for a license. Do we have any practical evidence that IPR owners actually care? What typically happens in practice, among good-faith practitioners, is that there won't be any GPL (or Apache, or Mozilla, or ...) implementation of the patented technology at all, because the necessary rights cannot be acquired. Doesn't that sound like a bug in the OSS licenses to you, assuming the desired result is to make the Internet work better? 1) I don't believe this is a 'send a postcard' license. If you read Mark's patent license, it starts with: Upon request, RedPhone Security will ... I interpret this to mean that unless RedPhone responds to your requests, you have not received any rights. Is this incorrect? I'm assuming you will get a postcard in reply, certainly. There are examples where companies won't respond to requests for these type of RF patent licenses. The phrase you quote doesn't allow for that. A recent example that came to mind was related to the BOCU patent by IBM: http://permalink.gmane.org/gmane.text.unicode.devel/23256 I won't respond here on that specific issue. A different problem is if the patent is owned by a small company, and the company goes away. Normally the patent will fall into the hands of whoever strips the assets. That's why a carefully constructed perpetual RF license is needed, in any case. Still, I'm not sure even a send-a-postcard patent license would be compatible with free software licenses. Sending the postcard appear to be an additional requirement, something that some free software licenses explicitly forbid. I think that is a bug in the OSS licenses. Whatever you or I may think of patent law, it isn't going away, and the OSS licenses need to deal with it realistically IMHO. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Simon, Do you have examples of licenses/IPR declarations that work better with GPL and other forms of open source? Something for Mark and the rest of us to use as a model, perhaps? Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Brian E Carpenter [EMAIL PROTECTED] writes: On 2007-04-11 10:08, Simon Josefsson wrote: Brian E Carpenter [EMAIL PROTECTED] writes: Simon, Can you identify any instance of a non-profit GPL implementor or distributor being sued for not having sent a postcard for the style of RF license you are objecting to? Brian, two responses: 1) You seem to assume that GPL implementers would violate the patent license by redistributing their code without sending a postcard. In order words, your question assumes and implies bad-faith amongst GPL implementers. Not specifically. My question is a practical one. People who receive open source code, tweak it, and install it may often be completely unaware that they should be asking for a license. Do we have any practical evidence that IPR owners actually care? I don't know. However, I don't understand how this aspect matters. Let me explain how I see things, and you can pinpoint where our logic differ. I believe that any IPR owner would first contact this person and ask him to follow their patent license. Then they either they play by the rules, and requests the license, or they don't (and a lawsuit may happen). Is the IETF interested in supporting people who doesn't follow the rules? I believe these people can and should be educated, but the IETF should not write its rules assuming that people will not follow rules. What typically happens in practice, among good-faith practitioners, is that there won't be any GPL (or Apache, or Mozilla, or ...) implementation of the patented technology at all, because the necessary rights cannot be acquired. Doesn't that sound like a bug in the OSS licenses to you, assuming the desired result is to make the Internet work better? The assumption is false: the goal of free software is not to make the Internet work better. Would you also claim that Microsoft Windows license has a bug in it because it does not permit certain things (i.e., creating patches yourself to avoid massive security holes) that would make the Internet work better? I hope you get the point that your assumption here was flawed. The IETF has the goal of making the Internet work better. Thus, the IETF has to accept the license reality, both proprietary and free software, and do whatever leads to a better Internet. I don't see how favoring proprietary software makes the Internet work better, rather the opposite. Thus I believe the IETF can be more free software friendly, especially since doing that isn't in conflict with proprietary vendors. The proprietary vendors needs similar rights as the free software community does. The only reason I can see to be non-friendly to the free software community would be because the market share for proprietary vendors would decline in favor of free software. But I have not seen any convincing results that indicate that this would modify how well the Internet works, which should be the IETF's primary concern. (I would argue that making the Internet run on free software actually would make the Internet better, because it is easier to fix security bugs, although I suppose it will be difficult to find consensus on this here.) 1) I don't believe this is a 'send a postcard' license. If you read Mark's patent license, it starts with: Upon request, RedPhone Security will ... I interpret this to mean that unless RedPhone responds to your requests, you have not received any rights. Is this incorrect? I'm assuming you will get a postcard in reply, certainly. There are examples where companies won't respond to requests for these type of RF patent licenses. The phrase you quote doesn't allow for that. But reality allow for that. The URLs I quoted indicate that this do happen. It is better if the license were written in a way to avoid this problem. A different problem is if the patent is owned by a small company, and the company goes away. Normally the patent will fall into the hands of whoever strips the assets. That's why a carefully constructed perpetual RF license is needed, in any case. Right, and a carefully constructed license would avoid the requirement to send and receive postcards. Still, I'm not sure even a send-a-postcard patent license would be compatible with free software licenses. Sending the postcard appear to be an additional requirement, something that some free software licenses explicitly forbid. I think that is a bug in the OSS licenses. Whatever you or I may think of patent law, it isn't going away, and the OSS licenses need to deal with it realistically IMHO. I disagree. Seen from the point of view of the goals of free software, there is no bug. If the IETF has conflicting goals, and I believe that it clearly does here, it will have to deal with the reality in order to further its goals. You may argue that free software licenses should change, and if you participate in that process, you may very well influence it.
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Jari Arkko [EMAIL PROTECTED] writes: Simon, Do you have examples of licenses/IPR declarations that work better with GPL and other forms of open source? Something for Mark and the rest of us to use as a model, perhaps? Jari, thank you for asking! I am working on a document with guidelines for free standards in the IETF, and I have written the following regarding patents. Much of the material came from this thread. I have not yet discussed this document in the free software community (which I intend to do before publishing it), so be aware that things may change considerably. /Simon 4. Patent Concerns The IETF rules (see [RFC3978]) demands that authors notify the IETF when they submit documents with patented technology (as far as the authors are aware of). Third parties are also encouraged to submit disclosures about patented technology in others' documents. This process does not guarantee that all IETF documents will have no IPR concerns. That was not the intention, and there are several documents with a complicated IPR situation. One example is the standards-track use of the patented RSA public-key algorithm. Fortunately, the IETF process encourages and makes it easy to verify whether there are known patents for a particular document. If a documented is known to be patented, that may complicate the use of the document in free software environments. The first conclusion here is that readers will have to search the online IETF IPR Disclosure page at http://www.ietf.org/ipr/ for the document they are interested in. 4.1. What To Look For In A Patent Disclosure An alternative title for this section may be 'How To Write A Free- Software Friendly Patent Disclosure'. Words to look for in a patent license is free-of-charge, world-wide, royaltee-free, perpetual and non-exclusive right to the patent. Some patent disclosures demands that you to write to the patent owner and request a license. Such a clause leads to problems if a company goes away or won't respond to requests. Depending on the text used, it may even require that every user of the software is required to apply for a license. That is not feasible for free software, which is widely distributed to everyone. The recommendation here is that the license should grant rights directly to third parties. Some patent licenses restricts how you can use the technology. This causes an incompatibility with many free software licenses, which says that no additional restrictions may be placed on the redistribution of the software. Further, free software is intended to be generally useful. If one field-of-use is restricted, that goes against the spirit of free software. The recommendation here is that patent licenses should not impose any additional restrictions before granting the rights. 4.2. Handling Submarine Patents In some cases, patent disclosures are filed late in the process. It may after a WG has accepted a document, after it has been last- called, after it has been approved by the IESG, or even after it has been published as an RFC. We call such late notification of earlier patents as a submarine patent. If the document has already been approved as an RFC, the published document itself cannot be modified. However, the documents' status on the standards track can be modified by publishing an approved document containing the reasons for doing so. If the patent disclosure is not considered to grant sufficient rights to third parties, it is recommended to consider alternative technologies and to write a document moving the RFC with patented technology off the standards track. In the other situations, it is recommended that interested parties evaluate the patent disclosure and re-evaluate their earlier decision to accept, last-call or approve the document. 4.3. Example License Text Here is a simplistic patent license that would grant third parties the necessary rights in order to use it in free software. X grants a worldwide, non-exclusive, fully-paid, perpetual, royaltee-free patent license to everyone for any purpose. [XXX: Most likely, this section will be heavily modified based on feedback from the community.] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Just one comment: Brian E Carpenter writes: On 2007-04-11 10:08, Simon Josefsson wrote: What typically happens in practice, among good-faith practitioners, is that there won't be any GPL (or Apache, or Mozilla, or ...) implementation of the patented technology at all, because the necessary rights cannot be acquired. Doesn't that sound like a bug in the OSS licenses to you, assuming the desired result is to make the Internet work better? In this kind of situation, what would _you_ choose? [ ] Apply for an IPR license/sign an NDA/do other paperwork [ ] Violate someone's something [ ] Go do something else My choice tends to be the last, because my goal is generally not to implement some specific technology, it is to increase people's happiness and productivity. I can do that by implementing whatever Mark has patented. Or in any of ten thousand other ways. See? Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wed, 11 Apr 2007, Jari Arkko wrote: Do you have examples of licenses/IPR declarations that work better with GPL and other forms of open source? Something for Mark and the rest of us to use as a model, perhaps? A recent slap given by Apache to Sun http://www.apache.org/jcp/sunopenletter.html implies that the Java Community Process has very open requirements on patent licences granted via the Java Specification Participation Agreement. The ASF thought a lot about patent licensing to produce the Apache Licence 2.0 - most other patent-aware open source licences are sponsored by businesses rather than non-profit foundations. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FORTIES CROMARTY FORTH: WEST OR SOUTHWEST 5 OR 6 DECREASING 3 OR 4. SLIGHT OR MODERATE, OCCASIONALLY ROUGH IN FORTIES. RAIN AT TIMES. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Simon, I am working on a document with guidelines for free standards in the Great! IETF, and I have written the following regarding patents. Much of the material came from this thread. I have not yet discussed this document in the free software community (which I intend to do before publishing it), so be aware that things may change considerably. Ok. But let me clarify my question. I was specifically after running code that has worked well in some case, and not so much specific new text. (Running code would show that at least some open source project was OK with the license and that at least some specific set of company lawyers were OK with making such a license.) Maybe we should move this thread to IPR WG... Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Simon, 4.3. Example License Text Here is a simplistic patent license that would grant third parties the necessary rights in order to use it in free software. X grants a worldwide, non-exclusive, fully-paid, perpetual, royaltee-free patent license to everyone for any purpose. [XXX: Most likely, this section will be heavily modified based on feedback from the community.] As you certainly realise, this isn't going to happen. I am not speaking for any particular company, and certainly not for the one that pays me, but it's clear that no company in today's IT market and today's legal environment could make such a grant. Any RF license is going to come with conditions that protect the IPR owner in certain ways. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On 2007-04-11 11:34, Arnt Gulbrandsen wrote: Just one comment: Brian E Carpenter writes: On 2007-04-11 10:08, Simon Josefsson wrote: What typically happens in practice, among good-faith practitioners, is that there won't be any GPL (or Apache, or Mozilla, or ...) implementation of the patented technology atall, because the necessary rights cannot be acquired. Doesn't that sound like a bug in the OSS licenses to you, assuming the desired result is to make the Internet work better? In this kind of situation, what would _you_ choose? [ ] Apply for an IPR license/sign an NDA/do other paperwork [ ] Violate someone's something [ ] Go do something else My choice tends to be the last, because my goal is generally not to implement some specific technology, it is to increase people's happiness and productivity. I can do that by implementing whatever Mark has patented. Or in any of ten thousand other ways. See? [X] Use a different OSS license that doesn't have this perceived problem. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Jari Arkko [EMAIL PROTECTED] writes: Ok. But let me clarify my question. I was specifically after running code that has worked well in some case, and not so much specific new text. (Running code would show that at least some open source project was OK with the license and that at least some specific set of company lawyers were OK with making such a license.) Oh, I see. As far as company lawyers, I can think of RedHat's patent policy: http://www.redhat.com/legal/patent_policy.html I realize that this is not a 'Patent License' but rather a 'Promise not to enforce', but the end result for free software developers is the same, I think. I do not know which patents RedHat owns or whether there is any free software that depends on this promise, though. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wed, Apr 11, 2007 at 10:27:31AM +0200, Brian E Carpenter wrote: 1) You seem to assume that GPL implementers would violate the patent license by redistributing their code without sending a postcard. In order words, your question assumes and implies bad-faith amongst GPL implementers. Not specifically. My question is a practical one. People who receive open source code, tweak it, and install it may often be completely unaware that they should be asking for a license. Do we have any practical evidence that IPR owners actually care? Well, if IPR owners don't actually care, why are they asking people to send a postcard? It would seem to be an unnecessary administrative burden for the IPR owners, yes? What typically happens in practice, among good-faith practitioners, is that there won't be any GPL (or Apache, or Mozilla, or ...) implementation of the patented technology at all, because the necessary rights cannot be acquired. Doesn't that sound like a bug in the OSS licenses to you, assuming the desired result is to make the Internet work better? It's not bug in the OSS licenses at all. Rather, it's a choice (based on ethics/legal paranoia/whatever) of implementors not to risk having to spend millions and millions of dollars defending a patent lawsuit. In some cases, paranoid corporate lawyers might be involved as well, telling implementors that if they can't fulfill the terms of the patent license, they may not write or release code which could potentially result in a lawsuit claiming the person implementing said patented technology was inducing end users to infringe (since it's pretty much axiomatic that 99.99% of people downloading code won't know that they need to send a postcard). I suppose if the RF license allow a program to automatically send an HTTP request to automatically request a license --- but that seems like a great way to slashdot the IPR holder's web servers, if an open source software package using said RF license gets popular! Let's reverse the question --- why do IPR holders feel they need people to explicitly request a royalty-free license? It seems like it's just unnecessary administrative work on their end for no cost. Unless, of course, it's not perpetual, as was alleged with a certain XML office document patent grant, which meant that a certain company could pretend to release sofware under what appeared to be a Royalty Free License, but then required every user to go on bended knee to request a license, which could be denied at any point in the future if said company changed its mind. The state of Massachusetts chose to use the OASIS Open Document format partially because of this concern, so such patent licensing choices can make a huge difference in terms of standards adoption. So to me this seems to be more of a question similar to the controversy of labelling food as Organic. There will be companies that may want to label their patent licenses as Royalty Free, but not necessarily make them be perpetual, or require each individual end user to fill out a form and mail it via paper mail and wait for a paper response before they wouldn't be infringing the patent --- but the net result of it may be to inhibit using the patent unless actual dollars are paid to the IPR holder. No question, that is the right of the IPR holder to do so, to the extent granted by the relevant legal jurisdition(s). But the question is whether they should be allowed to call such a patent royalty free --- either by creating some set of standards which are trademarked, much like the Open Source Definition did for copyrights --- or by some organization, like the IETF, refusing to a characterize a patent license as being royalty free (or pick some other term denoting that the license could actually be practically used in Open Source Software). And like the massive debates over organic foods, there will no doubt be a lot of debate and disagreement about what those standards should be. - Ted Disclaimer: These are my own personal opinions and not necessarily the opinions of my employer; I'm not important enough to affect the opinions of my employer. :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Brian E Carpenter [EMAIL PROTECTED] writes: On 2007-04-11 11:34, Arnt Gulbrandsen wrote: Just one comment: Brian E Carpenter writes: On 2007-04-11 10:08, Simon Josefsson wrote: What typically happens in practice, among good-faith practitioners, is that there won't be any GPL (or Apache, or Mozilla, or ...) implementation of the patented technology at all, because the necessary rights cannot be acquired. Doesn't that sound like a bug in the OSS licenses to you, assuming the desired result is to make the Internet work better? In this kind of situation, what would _you_ choose? [ ] Apply for an IPR license/sign an NDA/do other paperwork [ ] Violate someone's something [ ] Go do something else My choice tends to be the last, because my goal is generally not to implement some specific technology, it is to increase people's happiness and productivity. I can do that by implementing whatever Mark has patented. Or in any of ten thousand other ways. See? [X] Use a different OSS license that doesn't have this perceived problem. How would using, say, the MIT or BSD license give you or your users the right to violate someone's patent? The problem would be the same even if you were to release your implementation under the Windows or Mac OS X license. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Ted, Well, if IPR owners don't actually care, why are they asking people to send a postcard? It would seem to be an unnecessary administrative burden for the IPR owners, yes? My assumption is that they care if the party that fails to send a postcard is one of their competitors. That's what the defensive clauses in these licenses are all about, afaics. ... Disclaimer: These are my own personal opinions and not necessarily the opinions of my employer; I'm not important enough to affect the opinions of my employer. :-) Ditto. (Full disclosure: Ted and I have the same employer, but we're allowed to disagree :-) Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On 04/11/2007 05:22 AM, Simon Josefsson wrote: I am working on a document with guidelines for free standards in the IETF Please don't use free standards this way. The IETF produces free standards. Some of those standards have IPR licenses that you don't like. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Scott W Brim [EMAIL PROTECTED] writes: On 04/11/2007 05:22 AM, Simon Josefsson wrote: I am working on a document with guidelines for free standards in the IETF Please don't use free standards this way. The IETF produces free standards. According to what definition of 'free standards'? Some of those standards have IPR licenses that you don't like. Yes, and that would make them non-free to me. The copyright license also makes IETF standards non-free, and here at least one major GNU/Linux distribution agrees with me. Anyway, the point of having optional guidelines is that people who do not agree with the ideas behind the guidelines don't have to follow them. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wed, Apr 11, 2007 at 01:54:53PM +0200, Brian E Carpenter wrote: Well, if IPR owners don't actually care, why are they asking people to send a postcard? It would seem to be an unnecessary administrative burden for the IPR owners, yes? My assumption is that they care if the party that fails to send a postcard is one of their competitors. That's what the defensive clauses in these licenses are all about, afaics. So if there is a license which is not sublicensable, where if a competitor wanted to field a product that required the patent license --- I would rather doubt it if the competitor would want to ship software or hardware where each individual end user had to send a signed, notarized paper form to the IPR holder, and wait for a paper response, before they would be allowed to use that product. So that brings up an interesting question. Suppose an IPR holder approached the IETF, with a claim that they were offerring an royalty free license, but one which was not sublicensable and which contained extremely onerous terms that applied to the individual end user. (``After receiving an individually framed patent license, the end user must jump up and down 17 times on one foot while chanting, Hail Billy, the Gates is with you, I promise to never use Open Document.'' :-) Now suppose the IPR disclosure filed with the IETF didn't say anything at all about any reasonable and nondiscriminatory licenses alternative to said royalty free license. At this point, we could end up with a situation where a company tries to implement an IETF standard, realizes that the reliance on the royalty free license is untenable, goes back to the IPR holder, only discover that the only other alternatives are under terms which are anything but RAND. So at the minimum, if we're not going to establish requirements on royalty-free licenses being at least (a) perpetual, and (b) automatically sub-licensable, (maybe those could be defined as part of reasonable as it applies to RF licenses?) it would probably be a good idea to require a statement by the IPR holders to state their position on a RAND licensing as well. Otherwise, we could end up in a situation where we discover after the fact that the only way to implement the standard is via a completely unreasonable set of royalty-free terms that make it completely useless for either an OSS or commercial/propietary product, and with no statement about RAND licensing terms. Basically, there seems to be a loophole in our current wording which could allow a bad actor who was determined to use patents as a strategic weapon a way to lay trap which could seriously compromise the deployment of an IETF standard. - Ted P.S. For the record, my personal list of reasonable RF license terms include: 1) Perpetual (MUST) 2) Sub-licensable (MUST) 3) Restriction to essential claims necessary to implement a standard (MAY) 4) Defensive clauses which revoke a patent license in the event of patent litigation (MAY) (Some OSS advocates will disagree with me on #3, and there I will agree with Brian that if an OSS requires a universal patent license, it's probably a bug in the OSS license --- and the ones who try to use the OSD language about fields of endeavor are trying to apply standards designed for copyright licenses, and they may not be appropriate for patent licenses. But there will be plenty of room to debate this particular issue --- but probably better to do it in the IPR working group. :-) --- Disclaimer: These are my own personal opinions and not necessarily the opinions of my employer; I'm not important enough to affect the pinions of my employer. :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wed, Apr 11, 2007 at 01:54:53PM +0200, Brian E Carpenter wrote: Ted, Well, if IPR owners don't actually care, why are they asking people to send a postcard? It would seem to be an unnecessary administrative burden for the IPR owners, yes? My assumption is that they care if the party that fails to send a postcard is one of their competitors. That's what the defensive clauses in these licenses are all about, afaics. I'm not sure I understand the Upon request...will provide clause. Actually, I'm sure I don't understand it... Does it in any significantly enforcable way *require* RedPhone Security to do anything? If so, then all the competitor has to do is send a postcard, so the defensive value is effectively zero -- anyone who is a significant competitor can certainly afford a postcard. If, on the other hand, it imposes no real requirements on RedPhone Security, what does it do? Why is it there? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wed, Apr 11, 2007 at 01:54:53PM +0200, Brian E Carpenter wrote: Ted, Well, if IPR owners don't actually care, why are they asking people to send a postcard? It would seem to be an unnecessary administrative burden for the IPR owners, yes? My assumption is that they care if the party that fails to send a postcard is one of their competitors. That's what the defensive clauses in these licenses are all about, afaics. I was thinking about your response, and I wonder if we might be talking past each other. The concern that I think a number of raising about send a postcard specifically about patent licenses which are not sub-licensable, so that each individual end-user has to request their own individual patent license. Were you perhaps thinking of the scenario where only the a developer had to do is to send a postcard to request a patent license? If so, I agree that's much less of an issue, although it still could potentially be considered too onerous by some. We could construct some really extreme ways such a Royalty Free license could be worded that illustrates how our lack of definition of Royalty Free in the IPR disclosure template could come back to haunt us. Suppose a company declared that they would make a Royalty Free license available. If they subsequently published the the following, at which point would it be construed that they had violated the IPR declaration (of which I hope some lawyer has commented about whether or not it is legally binding)? This patent license is not sub-licensable. Each developer and individual end user must travel in person to the MegaCorp offices located in Nome, Alaska, and apply for a royalty-free patent license, which shall not be refused unless you or your company has ever used or developed software which utilizes the Open Document format. If the answer is that a company could declare in an IPR declaration that they are offerring an Royalty Free license, and not make any promises for offerring RAND terms, and then could offer their patent under the above license without sufferring any legal consequences, I'd argue we have a significant hole in our processes. - Ted Disclaimer: These are my own personal opinions and not necessarily the opinions of my employer; I'm not important enough to affect the opinions of my employer. :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Hello; On Apr 11, 2007, at 9:33 AM, [EMAIL PROTECTED] wrote: On Wed, Apr 11, 2007 at 01:54:53PM +0200, Brian E Carpenter wrote: Ted, Well, if IPR owners don't actually care, why are they asking people to send a postcard? It would seem to be an unnecessary administrative burden for the IPR owners, yes? My assumption is that they care if the party that fails to send a postcard is one of their competitors. That's what the defensive clauses in these licenses are all about, afaics. I'm not sure I understand the Upon request...will provide clause. Actually, I'm sure I don't understand it... Does it in any significantly enforcable way *require* RedPhone Security to do anything? If so, then all the competitor has to do is send a postcard, so the defensive value is effectively zero -- anyone who is a significant competitor can certainly afford a postcard. If, on the other hand, it imposes no real requirements on RedPhone Security, what does it do? Why is it there? I always figured that these things were poison pills - if company A sues company B about a password infringement, company B will counter sue, and, for company A, yank any applicable RAND license, and look to see if A did things like send in the postcard. (Or, if A was diligent about sending them in, it provides a handy list of the patents for B to hassle them about.) It might also be useful for performance evaluations, to see how many people are using your patents. Regards Marshall ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Apr 11, 2007, at 4:54 AM, Brian E Carpenter wrote: Ted, Well, if IPR owners don't actually care, why are they asking people to send a postcard? It would seem to be an unnecessary administrative burden for the IPR owners, yes? My assumption is that they care if the party that fails to send a postcard is one of their competitors. That's what the defensive clauses in these licenses are all about, afaics. ... Disclaimer: These are my own personal opinions and not necessarily the opinions of my employer; I'm not important enough to affect the opinions of my employer. :-) Ditto. (Full disclosure: Ted and I have the same employer, but we're allowed to disagree :-) A statement of claims and conditions should also protect software distribution as a practical matter, or this limitation should be clearly disclosed. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Jari Arkko wrote: Simon, Do you have examples of licenses/IPR declarations that work better with GPL and other forms of open source? Something for Mark and the rest of us to use as a model, perhaps? Non-assert works well... http://www.ietf.org/ietf/IPR/nokia-updated-ipr-draft-saifullah-rohc-ip-addr-comp-context-replicat.txt Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wednesday, April 11, 2007 11:16:30 AM +0200 Simon Josefsson [EMAIL PROTECTED] wrote: The assumption is false: the goal of free software is not to make the Internet work better. The assumption is not false. The goal of the IETF is to make the Internet work better. I assume Brian chose those words with care; they are taken directly from the IETF's mission statement, RFC3935. The IETF has the goal of making the Internet work better. Thus, the IETF has to accept the license reality, both proprietary and free software, and do whatever leads to a better Internet. That does not always mean discarding technologies because the people who developed them want to protect their legal right to benefit from their invention, or to protect themselves from liability. The reality is that the law is not going away, patents are not going away, and both the IETF and the free software community (to the extent that such a thing exists) need to learn to deal with that. Disclaimer: I am not a lawyer; this message is not legal advice. For the record, I think your concerns about this particular license are overstated. Neither this patent license nor the open-source software licenses you quote are as buggy as you seem to think they are. For example, the patent license contains the following text, which you quoted: This general use license granted to manufacturers also flows down to sublicensees and users. This would appear to have the effect that only the original implementor of the patented technology would need to obtain a license from RedPhone; he would then simply include in the software license a recursive sublicense for the patent. The field-of-use restriction is annoying, of course, but I don't think it's actually fatal in this case. The GPL does indeed prohibit you; that is, the GPL licensee, from imposing futher restrictions on recipients exercise of rights granted within the GPL. However, it does not prevent such restrictions from already existing; the GPL does not prevent you from adding support to GPL'd software for patented crypto technology and then distributing the result, provided the patent license does not require you do place additional restrictions on the activities of people you distribute to. In fact, the most common problem I've heard of with GPL incompatibility as it relates to patents is that the GPL prevents adding a restriction that requires preparers of derivative works to license any relevant IPR that they own. The text you referenced in the Mozilla and Apache licenses are examples of such requirements, and make those licenses GPL-incompatible. The Mozilla license covers this explicitly, again in the text you quote: The Initial Developer hereby grants... subject to third party intellectual property claims. Of course, that's not really the important part, since most people are not the Initial Developer. What you really want is section 2.2, Subject to third party intellectual property claims, each Contributor hereby grants In either case, what is going on here is that anyone who contributes code to software covered by that license must grant licenses to any relevant IPR that he owns; it explicitly excludes IPR owned by someone else. Thus, it is possible to include patented crypto in software covered by the Mozilla license, even if the patent holder requires every user to pay a large fee to use the patented technology. The section you refer to from the Apache license is similar - it consists of a license grant by each contributor of rights held _by that contributor_. The grant does not cover IPR not held by the distributor. In any case, the text you quote from the Mozilla and Apache licenses has nothing to do with the argument you are trying to make; it has no effect on the ability to create and distribute software under these licenses which implements technology patented by someone other than the contributor. What makes these clauses problematic is that they cause the licenses that contain them to be GPL-incompatible (but not necessarily non-free). -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wednesday, April 11, 2007 11:34:42 AM -0400 Jeffrey Hutzelman [EMAIL PROTECTED] wrote: For the record, I think your concerns about this particular license are overstated. Neither this patent license nor the open-source software licenses you quote are as buggy as you seem to think they are. For example, the patent license contains the following text, which you quoted: This general use license granted to manufacturers also flows down to sublicensees and users. This would appear to have the effect that only the original implementor of the patented technology would need to obtain a license from RedPhone; he would then simply include in the software license a recursive sublicense for the patent. Hm. Unfortunately, it seems there is other text that is problematic... This... The Protected Assurance System Functions listed below (the PAS Functions) define a set of functionality that Manufacturers under this General Use License (e.g. manufacturers of receiver / server components) must ensure is NOT implemented or provided to its users. ... would indeed appear to require anyone distributing an implementation to impose additional restrictions, which is a problem. Also, this is very bad: In the event that a Manufacturer has (a) only been granted a General Use License and (b) implemented and released to end users any PAS Functions, such events shall cause the General Use License of that Manufacturer to be immediately revoked, and any license rights conferred to any users of the system that has implemented any PAS Functions (above) shall be likewise revoked. This appears to say that if someone violates the license terms, then anyone who received a sublicense from them, directly or indirectly, is also screwed, even if the user has not violated the terms of the license. This is extremely unfriendly, not just to open source but to users in general. Finally, schedule B requires that specific text be unambiguously displayed at time of system installation. This requirement is impractical and in any case impossible for open-source implementors to enforce. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
--On Wednesday, 11 April, 2007 09:43 -0400 Theodore Tso [EMAIL PROTECTED] wrote: On Wed, Apr 11, 2007 at 01:54:53PM +0200, Brian E Carpenter wrote: ... My assumption is that they care if the party that fails to send a postcard is one of their competitors. That's what the defensive clauses in these licenses are all about, afaics. I was thinking about your response, and I wonder if we might be talking past each other. The concern that I think a number of raising about send a postcard specifically about patent licenses which are not sub-licensable, so that each individual end-user has to request their own individual patent license. ... We could construct some really extreme ways such a Royalty Free license could be worded that illustrates how our lack of definition of Royalty Free in the IPR disclosure template could come back to haunt us. Suppose a company declared that they would make a Royalty Free license available. If they subsequently published the the following, at which point would it be construed that they had violated the IPR declaration (of which I hope some lawyer has commented about whether or not it is legally binding)? ... If the answer is that a company could declare in an IPR declaration that they are offerring an Royalty Free license, and not make any promises for offerring RAND terms, and then could offer their patent under the above license without sufferring any legal consequences, I'd argue we have a significant hole in our processes. Ted, jumping ahead a little bit, how much of your concern would be eliminated if that entry in the template said Royalty Free and RAND (or RAND and Royalty Free), rather than just RF? I agree that RF and totally unreasonable is a possible case, but am trying to understand whether we have a disconnect about the language we have used or about some general and important principle? I would ask just about the same question about questions of revocability. Independent of what the other provisions are, should we insist that any grant of rights incorporated in an IPR disclosure be permanent and irrevocable, or at least permanent and irrevocable in the absence of specific violation of other terms? How much of your concern would that eliminate? john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Ted, jumping ahead a little bit, how much of your concern would be eliminated if that entry in the template said Royalty Free and RAND (or RAND and Royalty Free), rather than just RF? I agree that RF and totally unreasonable is a possible case, but am trying to understand whether we have a disconnect about the language we have used or about some general and important principle? A useful convention that's being used more and more is the term RANDz, which means RAND without monetary compensation. This captures both the monetary aspect as well as the reasonableness of other terms. Of course, to avoid any uncertainty, it would be helpful to define RANDz somewhere in the IETF policy documents (RFC 3979, etc.). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wed, Apr 11, 2007 at 01:24:02PM -0400, John C Klensin wrote: Ted, jumping ahead a little bit, how much of your concern would be eliminated if that entry in the template said Royalty Free and RAND (or RAND and Royalty Free), rather than just RF? I agree that RF and totally unreasonable is a possible case, but am trying to understand whether we have a disconnect about the language we have used or about some general and important principle? I believe that this is the minimum we should have just simply to protect the needs of commercial/propietary consumers of our standards, so yes, that addresses much of my concern. I believe it would be better if Royalty Free were more strictly defined to include irrevocability *AND* either (a) the ability to sublicense or (b) the ability for end-users to automatically get a grant of permission without having to perform any explicit action, as was done in Microsoft's Open Specification Promise. Unlike some OSS advocates, I don't feel a particular need to to require a patent license which is valid for any field of endeavor; just the essential claims necessary to implement an IETF standard is IMHO sufficient (realistically I doubt many IPR holders would be willing grant more than that). And I suspect there is general consensus that terms which revoke permission in case of patent litgation (even the GPLv3 has such terms) is not controversial at all. But regardless of what definition we end up, I think we should more explicitly define what we mean by Royalty Free, just to prevent companies from engaging in PR/Marketing games. If it ends up being a definition which means that it might not necessarily be useful to OSS implementors (i.e., the end-user must in apply in person at the offices of MegaCorp in Nome, Alaska example), at least it's well defined and people are put on notice that they can't trust the IETF when we say something is Royalty Free that the specification could be really implemented by Open Source Software developers without doing more digging into the details of the license --- which might not be in the IPR disclosure. It's not ideal, but at least people would know where they stand. - Ted Disclaimer: Any opinions expressed in this message are my own and does not necessarily reflect the opinions of my employer. I'm not important enough to affect the opinions of my employer. :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wed, 11 Apr 2007, Theodore Tso wrote: ... Unlike some OSS advocates, I don't feel a particular need to to require a patent license which is valid for any field of endeavor; just the essential claims necessary to implement an IETF standard is IMHO sufficient (realistically I doubt many IPR holders would be willing grant more than that). [...] FWIW, many declarations (taking the one shown by Joel as an example), permission is granted to technically necessary to implement the IETF standard spesification.. and similar has been seen in other declarations (possibly in the form, '.. to interoperate with XXX standard specification'). Does that allow you to implement everything in the specification if 'everything' is not 'technically necessary to implement' [for interoperability or otherwise]? MAYs? SHOULDs? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Dean: I'm still not clear on a few things: -- When did Russ Housley learn of the Patent Filing? I was aware that Mark Brown was working on a patent; however, I did not begin working with him until after his provisional patent application was filed. I did not see the claims until the filing became public. Since I knew that a patent was in the works, but I did not know the details, at the time we submitted the -00 draft to the repository (which was February 2006), I reminded Mark Brown that an IPR statement might be necessary. Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Dean: I always recuse myself from IESG evaluation of a document for which I am an author. You will find this to be the normal practice for all IESG members. I have no financial interest in PedPhone Security or the patent filing. I provided consulting services to RedPhone Security; it was a simple work for hire. I have no investors in my very small consulting company: Vigil Security, LLC. I am the owner, and I am the only full-time employee. Russ ItAt 07:47 PM 4/7/2007, Dean Anderson wrote: On Fri, 6 Apr 2007, Russ Housley wrote: Dean: I'm still not clear on a few things: -- When did Russ Housley learn of the Patent Filing? I was aware that Mark Brown was working on a patent; however, I did not begin working with him until after his provisional patent application was filed. I did not see the claims until the filing became public. Since I knew that a patent was in the works, but I did not know the details, at the time we submitted the -00 draft to the repository (which was February 2006), I reminded Mark Brown that an IPR statement might be necessary. How long did it take to produce the draft? Presumably, you must have started working on the project earlier than the date of submission. Did you know of the patent application before submission? I note that you recused yourself from the decisions made on this draft. That is commendable. It also implies that you stand to benefit somehow from the draft. But the patent (assuming it is granted) gives Brown and Wilke a monopoly on the technology. How is it, in general terms, that you will benefit from this draft? Do you have, perhaps, a favorable license agreement with Brown? Perhaps stock in Brown's company? Did Brown agree to invest in your company? Is there another patent application? As it stands, the information we have, indicates that only Brown stands to benefit, and this doesn't explain your involvement in these drafts. Some clarity on how you stand to benefit would be helpful. -- 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://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Todd: This is a follow-on note. Did you miss the earlier one, where I said: I was aware that Mark Brown was working on a patent; however, I did not begin working with him until after his provisional patent application was filed. I did not see the claims until the filing became public. Since I knew that a patent was in the works, but I did not know the details, at the time we submitted the -00 draft to the repository (which was February 2006), I reminded Mark Brown that an IPR statement might be necessary. Without seeing the claims, I could not know whether or not an IPR statement was required. Thus, the reminder to my coauthor was the appropriate action on my part. Russ At 12:23 PM 4/9/2007, todd glassey wrote: Russ - this isn't about Financial Interests its about the need to formally disclose something that you are uniquely aware of that the rest of the IETF isn't. That makes you liable IMHO for any damages someone suffers because of this failure to disclose. And since you are a IETF Manager its worse. Todd Glassey - Original Message - From: Russ Housley [EMAIL PROTECTED] To: Dean Anderson [EMAIL PROTECTED] Cc: Mark Brown [EMAIL PROTECTED]; ietf@ietf.org; iesg@ietf.org Sent: Monday, April 09, 2007 6:35 AM Subject: RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns Dean: I always recuse myself from IESG evaluation of a document for which I am an author. You will find this to be the normal practice for all IESG members. I have no financial interest in PedPhone Security or the patent filing. I provided consulting services to RedPhone Security; it was a simple work for hire. I have no investors in my very small consulting company: Vigil Security, LLC. I am the owner, and I am the only full-time employee. Russ ItAt 07:47 PM 4/7/2007, Dean Anderson wrote: On Fri, 6 Apr 2007, Russ Housley wrote: Dean: I'm still not clear on a few things: -- When did Russ Housley learn of the Patent Filing? I was aware that Mark Brown was working on a patent; however, I did not begin working with him until after his provisional patent application was filed. I did not see the claims until the filing became public. Since I knew that a patent was in the works, but I did not know the details, at the time we submitted the -00 draft to the repository (which was February 2006), I reminded Mark Brown that an IPR statement might be necessary. How long did it take to produce the draft? Presumably, you must have started working on the project earlier than the date of submission. Did you know of the patent application before submission? I note that you recused yourself from the decisions made on this draft. That is commendable. It also implies that you stand to benefit somehow from the draft. But the patent (assuming it is granted) gives Brown and Wilke a monopoly on the technology. How is it, in general terms, that you will benefit from this draft? Do you have, perhaps, a favorable license agreement with Brown? Perhaps stock in Brown's company? Did Brown agree to invest in your company? Is there another patent application? As it stands, the information we have, indicates that only Brown stands to benefit, and this doesn't explain your involvement in these drafts. Some clarity on how you stand to benefit would be helpful. -- 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://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Russ == Russ Housley [EMAIL PROTECTED] writes: Russ Dean: I always recuse myself from IESG evaluation of a Russ document for which I am an author. You will find this to be Russ the normal practice for all IESG members. Russ, Dean, Todd and others. Might I suggest that this part of this discussion has outlived its useful life on the ietf list. I'd like to thank all those who have participated for helping us understand what happened and for expressing their opinions. However, at this point, people seemed happy with taking the draft to the TLS working group. The authors asked for a week delay while they prepared a new IPR disclosure. That disclosure seems to have hit the IETF servers, so I'll touch back with the authors and then engage the TLS chairs. I'd like to suggest that discussions of what Russ should or should not have done,rehashing the facts of the situation yet again,and comments about specific legal obligations the IETF or its participants may or may not have with regard to this situation are not benefitting the ietf list. Thanks, Sam Hartman Security Area Director ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
What has happened in this case is very clear. I believe that Sam is handling the situation properly. Russ At 11:18 AM 4/7/2007, todd glassey wrote: Russ - does the current policy of the IETF's IPR disclosure process include what happens to a filing when the IPR disclosure is NOT FILED in a timely manner? Or the party here that was supposed to file the IPR Disclosure doesn't for whatever reason? These are real issues and effect the rights going forward so they are important. Also how is the IETF going to address postings to it that in those instances, the IPR disclosures are refused??? Todd Glassey - Original Message - From: Russ Housley [EMAIL PROTECTED] To: Dean Anderson [EMAIL PROTECTED] Cc: Mark Brown [EMAIL PROTECTED]; ietf@ietf.org Sent: Friday, April 06, 2007 2:37 PM Subject: RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns Dean: I'm still not clear on a few things: -- When did Russ Housley learn of the Patent Filing? I was aware that Mark Brown was working on a patent; however, I did not begin working with him until after his provisional patent application was filed. I did not see the claims until the filing became public. Since I knew that a patent was in the works, but I did not know the details, at the time we submitted the -00 draft to the repository (which was February 2006), I reminded Mark Brown that an IPR statement might be necessary. Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Simon, You observed: Normal IPR disclosure process is to alert the IETF community via the IETF website that a patent has been filed. I mistakenly thought that adding the boilerplate IPR statement at the top of the ID was sufficient to say what needed to be said. However, I don't think IETF requires the disclosure of an unpublished patent application. I believe that is required even for patent applications. RFC 3979 talks about patent applications in several places. You're right, please let me correct myself again here. My use of the term disclosure was sloppy. Here's what I was told by IESG: The IESG has been informed by Mark Brown that he had knowledge of the September 2005 patent application filed by his employer at the time he submitted draft-housley-tls-authz-extns. Accordingly, he was obligated to disclose the existence of this patent application upon making this submission. Making a required IPR disclosure after a draft is approved does not meet the requirement to promptly make the disclosure. According to section 7 of RFC 3979 failure to make a required disclosure is a failure of process. It should be noted that the above disclosure obligations apply to unpublished patent applications. When a patent application that is required to be disclosed is unpublished, the discloser must 'indicate that the claim is based on unpublished patent applications', but is not required to list the application number (see RFC 3978 Section 6.4.1). The content of the IETF-required IPR disclosure is this: 1. (YES) the discloser must 'indicate that the claim is based on unpublished patent applications' Not these: 2. (NO) list the application number (see RFC 3978 Section 6.4.1). 3. (NO) otherwise publish to the IETF the pending patent claims or description of the invention disclosed in any unpublished patent application(s) What I meant to say in my earlier email is that I don't think IETF requires disclosure of the body of the patent application, it's claims, etc. as in (3). I recognize that IETF does require the required IPR disclosure made via http://www.ietf.org/ipr-instructions as described in (1). This probably isn't news to any of you, but I wanted to correct my sloppy use of the term disclosure. Thanks, mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Dean == Dean Anderson [EMAIL PROTECTED] writes: Dean On Mon, 2 Apr 2007, Sam Hartman wrote: The IETf learned of Brown's patent application on 2006-11-29. Dean Can you elaborate? From whom or what source did the IETF Dean learn of the application? The IETF learned through an IPR disclosure filed by Brown. You can see that disclosure on our IPR disclosure page. At the IESG telechat held the next day, the IESG decided to withdraw approval and the general direction of its mesage to the community. A significant delay was introduced while the IESG reviewed its note with the IETF's lawyer. Please note that Russ recused himself from the decisions regarding this draft. Also note that the 2006-11-30 meeting was well before Russ knew he would be appointed IETF chair. Dean What was Housley's position on the earlier elliptic curve Dean crypto patent discussion that was suppressed on DNSEXT, and Dean was subsequently a topic of the PR action against me? Dean I don't have a record of Housley recusing himself from those Dean related issues. Dean -- Av8 Internet Prepared to pay a premium for better Dean service? www.av8.net faster, more reliable, better service Dean 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Harald, I want to apologize again for screwing up the IPR disclosure process. Normal IPR disclosure process is to alert the IETF community via the IETF website that a patent has been filed. I mistakenly thought that adding the boilerplate IPR statement at the top of the ID was sufficient to say what needed to be said. However, I don't think IETF requires the disclosure of an unpublished patent application. I finally made my disclosure on the IETF website (what I mistakenly thought was a second disclosure) after my patent got published. And, in all honesty, even this disclosure got delayed because I sought advice. Please note that the filing's publication, the delay, and the IPR disclosure all happened after the last IETF approval for the ID. The right thing to do is to use the IETF website the very day your file your first ID, and not hope that the verbiage atop the ID will somehow disclose that IPR filings are in progress. As a result of my mistakes, the IETF withdrew approval of the ID and explained the process to me. That's fair. But please keep in mind that even for important things, it's easy to make mistakes your first time through a process. --mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
--On 29. mars 2007 11:50 -0500 Mark Brown [EMAIL PROTECTED] wrote: Simon, I filed for patent (Jan and Sep 2005) and later promoted TLS authz (Feb 2006) in good faith. It is possible that the patent claims can be read more broadly than I expected, but that's a fairly detailed and unresolved legal question. I am working diligently to -- let me speak carefully -- explore if and how I can make a royalty free license grant to ensure that promoting TLS authz continues to be an act in good faith, while still protecting a way for my company to make money on its IPR. Mark, trying to understand your statement above: When you submitted draft-housley-00, August 2006, your submission included the text: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. You were clearly aware of your own patent filing. The Redphone IPR statement, https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=765, was filed on November 28, 2007; I cannot see any earlier filing in your name. I can reconcile those two things with your assurance of good faith in multiple ways: - You were not aware that section 6.2.1 of BCP 79 requires a disclosure as soon as reasonably possible. In this case, we need to update the informational material we provide to people who might submit I-Ds. - You were of the opinion that 15 months after the I-D filing was as soon as reasonably possible. In this case, we need to have an IETF debate on whether we think this is a reasonable assessment, and document the result of that discussion. - You were of the opinion that the patent applications were certainly not applicable to the specification in that draft, but changed your opinion later. - There is some logic here that I do not yet grasp, and I need further explanation. Rather than speculating about which of the alternatives above is true, I prefer to ask. Take care, Harald Alvestrand ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On 4 apr 2007, at 00.45, Mark Brown wrote: Harald, I want to apologize again for screwing up the IPR disclosure process. Normal IPR disclosure process is to alert the IETF community via the IETF website that a patent has been filed. I mistakenly thought that adding the boilerplate IPR statement at the top of the ID was sufficient to say what needed to be said. However, I don't think IETF requires the disclosure of an unpublished patent application. I believe that is required even for patent applications. RFC 3979 talks about patent applications in several places. I finally made my disclosure on the IETF website (what I mistakenly thought was a second disclosure) after my patent got published. And, in all honesty, even this disclosure got delayed because I sought advice. Please note that the filing's publication, the delay, and the IPR disclosure all happened after the last IETF approval for the ID. The right thing to do is to use the IETF website the very day your file your first ID, and not hope that the verbiage atop the ID will somehow disclose that IPR filings are in progress. Yes, filing IPR disclosures as soon as possible is what the rules says. As a result of my mistakes, the IETF withdrew approval of the ID and explained the process to me. That's fair. But please keep in mind that even for important things, it's easy to make mistakes your first time through a process. That is understandable. However, I believe it is in the best interest for the IETF community to put only one specification on the standards track to solve a particular problem. Some claim that it is possible to write a new document to address authorization in TLS without infringing on your patent. Thus, if these patents are problematic for TLS implementations, I think it is better to not publish this as a standards track document, and encourage alternative solutions to be published on the standards track. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Thanks Mark - this makes it clear that we need to work on our information materials, to make it clear to people what the requirement is. BTW, RFC 3979 doesn't make a difference between published and unpublished applications - both require a disclosure. Section 6.4.1 describes how to refer to an unpublished application - section 6.4.2 talks about the procedure for updating a disclosure when the status of a patent application changes. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Hi, Dean. First, with your permission I'd like to forward your comments to the ietf list. This is not a promise or invitation to forward future comments, but you have made comments on an issue that the community rather than the IESG decides and for your comments to be considered they need to be made available to the community. I can answer some of your questions. The IETf learned of Brown's patent application on 2006-11-29. At the IESG telechat held the next day, the IESG decided to withdraw approval and the general direction of its mesage to the community. A significant delay was introduced while the IESG reviewed its note with the IETF's lawyer. Please note that Russ recused himself from the decisions regarding this draft. Also note that the 2006-11-30 meeting was well before Russ knew he would be appointed IETF chair. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
[Dean Anderson] RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
to make this situation a little clearer than that, but doing so often involves taking risks of giving away a huge loophole. So I'm working to get good legal advice. In short, I am working to create a royalty-free license grant -- hopefully I can disclose it next week. With some luck, it will clarify the situation. Best regards, mark -Original Message- From: Simon Josefsson [mailto:[EMAIL PROTECTED] Sent: Thursday, March 29, 2007 10:12 AM To: Sam Hartman Cc: ietf@ietf.org; iesg@ietf.org; [EMAIL PROTECTED] Subject: Re: Withdrawal of Approval and Second Last Call: draft-housley- tls-authz-extns Sam Hartman [EMAIL PROTECTED] writes: Simon == Simon Josefsson [EMAIL PROTECTED] writes: Simon I don't care strongly about the standards track status. Simon However, speaking as implementer of the protocol: If the Simon document ends up as informational or experimental, I Simon request that we make an exception and allow the protocol to Simon use the already allocated IANA protocol constants. That Simon will avoid interoperability problems. I know the numbers Simon are allocated from the pool of numbers reserved for Simon standards track documents. There is no indication that we Simon are running out of numbers in that registry. Thus, given Simon the recall, I think the IETF should be flexible and not Simon re-assign the IANA allocated numbers at this point just Simon because of procedural reasons. Would you support publication on the standards track given the IPR situation as someone who has implemented? If the patent concern is valid and covers TLS libraries or other applications, no. However, as far as I am aware of the public information that is available, the situation appears to be that we don't know whether these patents apply and to what extent. I don't know whether the patents were filed in good or bad faith. More information from the patent holders may help here. If it is possible to implement the protocol without violating the patents, I would support publication. I've seen some claims that this may be possible. I have no interest in reading these patents myself, but my position would be influenced if someone knowledgeable reads the patents. Given the amount of patents out there, it would be unreasonable for us to move everything to informational just because someone finds something that may be relevant to a piece of work. The community needs to evaluate patent claims, and preferably reach conservative agreement (rough consensus is not good enough) on whether we should care about a particular patent or not. Input to that community evaluation process may be documentation of legal actions taken by a patent owner. Sometimes that may happen only after a document has been published. I would support down-grading standards track documents that later turn out to be patent-infected to informational. Doing so would avoid sending a message that the IETF supports patented technology, when the IETF community didn't know about the patents at publication time. For credibility of the process, I believe it is important that these decisions are only made based on publicly available information. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ---End Message--- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Mark Brown [EMAIL PROTECTED] writes: Simon, I filed for patent (Jan and Sep 2005) and later promoted TLS authz (Feb 2006) in good faith. It is possible that the patent claims can be read more broadly than I expected, but that's a fairly detailed and unresolved legal question. I am working diligently to -- let me speak carefully -- explore if and how I can make a royalty free license grant to ensure that promoting TLS authz continues to be an act in good faith, while still protecting a way for my company to make money on its IPR. Thanks for responding, Mark. In your opinion, what would an implementation have to do (implementation-wise) in order to infringe on your patent? Answering this, at least as far as your own informed opinion goes, would be useful in determining if there is value for the IETF community in standardizing this. If typical real-world TLS libraries in general would infringe on the patent, then I don't see how the IETF community in general would benefit from having this on the standards track. In fact, I see serious problems if the IETF standardize documents that the wide Internet community cannot use due to patent concerns. I have experienced some surprises when mixing law and Internet standards. To try to avoid surprises, I have hired IPR attorneys at two different firms to review my draft which proposes a royalty-free license grant. I expect any resulting license will be conditioned upon IETF acceptance of TLS authz as a standard. I hope to have concluded these services next week. Personally, I believe the temporal ordering should be the reversed. I think IPR questions are complicated in part because for some questions only a lawsuit can answer the question -- but we should all want to stay clear of these kinds of lawsuits! So answers seem to me to be in short supply. Making your thoughts and opinions clear and public goes a long way to disseminate the intent behind the patent. The IETF permits patented technology, but to make an informed decision how to respond to do we want to standardize this (i.e., the IETF-wide last call) there needs to be sufficient information available for participants to form an opinion. I want to craft the proposed license to make this situation a little clearer than that, but doing so often involves taking risks of giving away a huge loophole. So I'm working to get good legal advice. In short, I am working to create a royalty-free license grant -- hopefully I can disclose it next week. With some luck, it will clarify the situation. I look forward to reading it! Best regards, Simon Best regards, mark -Original Message- From: Simon Josefsson [mailto:[EMAIL PROTECTED] Sent: Thursday, March 29, 2007 10:12 AM To: Sam Hartman Cc: ietf@ietf.org; iesg@ietf.org; [EMAIL PROTECTED] Subject: Re: Withdrawal of Approval and Second Last Call: draft-housley- tls-authz-extns Sam Hartman [EMAIL PROTECTED] writes: Simon == Simon Josefsson [EMAIL PROTECTED] writes: Simon I don't care strongly about the standards track status. Simon However, speaking as implementer of the protocol: If the Simon document ends up as informational or experimental, I Simon request that we make an exception and allow the protocol to Simon use the already allocated IANA protocol constants. That Simon will avoid interoperability problems. I know the numbers Simon are allocated from the pool of numbers reserved for Simon standards track documents. There is no indication that we Simon are running out of numbers in that registry. Thus, given Simon the recall, I think the IETF should be flexible and not Simon re-assign the IANA allocated numbers at this point just Simon because of procedural reasons. Would you support publication on the standards track given the IPR situation as someone who has implemented? If the patent concern is valid and covers TLS libraries or other applications, no. However, as far as I am aware of the public information that is available, the situation appears to be that we don't know whether these patents apply and to what extent. I don't know whether the patents were filed in good or bad faith. More information from the patent holders may help here. If it is possible to implement the protocol without violating the patents, I would support publication. I've seen some claims that this may be possible. I have no interest in reading these patents myself, but my position would be influenced if someone knowledgeable reads the patents. Given the amount of patents out there, it would be unreasonable for us to move everything to informational just because someone finds something that may be relevant to a piece of work. The community needs to evaluate patent claims, and preferably reach conservative agreement (rough consensus is not good enough) on whether we should care about a particular patent
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On 03/30/2007 13:56 PM, John C Klensin wrote: For whatever it is worth, I think we need to step carefully around the distinction Paul makes above: there are almost certainly circumstances in which we should accept a broader grant of rights conditional on standardization and a narrower one if the technology is not standardized. I wish the IPR WG were paying a bit more attention to this sort of issue. This is a WG decision. IPR WG could produce guidance on the subject, but that's all. What are you looking for? On 03/30/2007 14:36 PM, Jeffrey Hutzelman wrote: If the IPR issues are the sole remaining factor in the IETF's decision as to whether to make a protocol a standard, then I think it is entirely reasonable for the IETF to consider an offer which would eliminate or at least mitigate those issues if the protocol were to become a standard. As Spencer pointed out, text like If included in a standard is common. We already do this implicitly. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
--On Saturday, 31 March, 2007 08:49 -0400 Scott W Brim [EMAIL PROTECTED] wrote: On 03/30/2007 13:56 PM, John C Klensin wrote: For whatever it is worth, I think we need to step carefully around the distinction Paul makes above: there are almost certainly circumstances in which we should accept a broader grant of rights conditional on standardization and a narrower one if the technology is not standardized. I wish the IPR WG were paying a bit more attention to this sort of issue. This is a WG decision. IPR WG could produce guidance on the subject, but that's all. What are you looking for? While I have an opinion on this particular case, I am more concerned about our precedents and decision-making processes than I am about it. Paul's note seemed to be saying the IETF should never accept material if IPR conditions are contingent on standardization. I don't know if that is what he intended, but I consider such a principle to be dangerous to us if generalized. I believe that any time the IETF considers adoption of an encumbered technology we need to weight importance of standardizing any technology in the area and the availability of alternatives against the particular encumbrances. I believe that is the case whether the issue is particular IPR terms (such as RAND iff standardization) or the specifics of the encumbrances. I believe that decision ultimately has to be an IETF one, not merely that of an individual WG. But I believe that advice from the appropriate WG is useful to the community in determining whether something should be standardized in spite of the IPR entanglements. To some extent, if a WG is given the opportunity to examine a particular proposal and chooses to not take it up and comment, that provides part of the answer: absent strong evidence from other sources, the proposal isn't valuable enough to standardize especially given IPR restrictions. On 03/30/2007 14:36 PM, Jeffrey Hutzelman wrote: If the IPR issues are the sole remaining factor in the IETF's decision as to whether to make a protocol a standard, then I think it is entirely reasonable for the IETF to consider an offer which would eliminate or at least mitigate those issues if the protocol were to become a standard. As Spencer pointed out, text like If included in a standard is common. We already do this implicitly. Indeed. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Jeff, As for informational vs an independent submission, I think there is a factor to be considered. It seems to me that an informational IETF document is a fine way to say this is a good idea, and we think this is the right way to do FOO, but we can't actually recommend it (for whatever reason). For example, we have at least one document that defines the use of elliptic curve cryptography with one of our protocols, which is informational because the working group that produced it didn't feel they could recommend it as a standard due to the hairy IPR issues surrounding that technology. Most people outside of this organization can't tell the difference between a standard and an informational document. They simply look at the label RFC and are done. And now you are trying to cut the line even thinner? Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On 2007-03-31 17:15, Eliot Lear wrote: Jeff, As for informational vs an independent submission, I think there is a factor to be considered. It seems to me that an informational IETF document is a fine way to say this is a good idea, and we think this is the right way to do FOO, but we can't actually recommend it (for whatever reason). For example, we have at least one document that defines the use of elliptic curve cryptography with one of our protocols, which is informational because the working group that produced it didn't feel they could recommend it as a standard due to the hairy IPR issues surrounding that technology. Most people outside of this organization can't tell the difference between a standard and an informational document. They simply look at the label RFC and are done. And now you are trying to cut the line even thinner? I think Jeff is trying to leave the line exactly where it is: the WG (or the IETF if there is no WG) decides case by case, within the envelope first defined by RFC 2026 and confirmed by RFC 3668 and 3979. Personally I prefer this to any doctrinaire rules or to reliance on precedent. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Simon, I filed for patent (Jan and Sep 2005) and later promoted TLS authz (Feb 2006) in good faith. It is possible that the patent claims can be read more broadly than I expected, but that's a fairly detailed and unresolved legal question. I am working diligently to -- let me speak carefully -- explore if and how I can make a royalty free license grant to ensure that promoting TLS authz continues to be an act in good faith, while still protecting a way for my company to make money on its IPR. I have experienced some surprises when mixing law and Internet standards. To try to avoid surprises, I have hired IPR attorneys at two different firms to review my draft which proposes a royalty-free license grant. I expect any resulting license will be conditioned upon IETF acceptance of TLS authz as a standard. I hope to have concluded these services next week. I think IPR questions are complicated in part because for some questions only a lawsuit can answer the question -- but we should all want to stay clear of these kinds of lawsuits! So answers seem to me to be in short supply. I want to craft the proposed license to make this situation a little clearer than that, but doing so often involves taking risks of giving away a huge loophole. So I'm working to get good legal advice. In short, I am working to create a royalty-free license grant -- hopefully I can disclose it next week. With some luck, it will clarify the situation. Best regards, mark -Original Message- From: Simon Josefsson [mailto:[EMAIL PROTECTED] Sent: Thursday, March 29, 2007 10:12 AM To: Sam Hartman Cc: ietf@ietf.org; iesg@ietf.org; [EMAIL PROTECTED] Subject: Re: Withdrawal of Approval and Second Last Call: draft-housley- tls-authz-extns Sam Hartman [EMAIL PROTECTED] writes: Simon == Simon Josefsson [EMAIL PROTECTED] writes: Simon I don't care strongly about the standards track status. Simon However, speaking as implementer of the protocol: If the Simon document ends up as informational or experimental, I Simon request that we make an exception and allow the protocol to Simon use the already allocated IANA protocol constants. That Simon will avoid interoperability problems. I know the numbers Simon are allocated from the pool of numbers reserved for Simon standards track documents. There is no indication that we Simon are running out of numbers in that registry. Thus, given Simon the recall, I think the IETF should be flexible and not Simon re-assign the IANA allocated numbers at this point just Simon because of procedural reasons. Would you support publication on the standards track given the IPR situation as someone who has implemented? If the patent concern is valid and covers TLS libraries or other applications, no. However, as far as I am aware of the public information that is available, the situation appears to be that we don't know whether these patents apply and to what extent. I don't know whether the patents were filed in good or bad faith. More information from the patent holders may help here. If it is possible to implement the protocol without violating the patents, I would support publication. I've seen some claims that this may be possible. I have no interest in reading these patents myself, but my position would be influenced if someone knowledgeable reads the patents. Given the amount of patents out there, it would be unreasonable for us to move everything to informational just because someone finds something that may be relevant to a piece of work. The community needs to evaluate patent claims, and preferably reach conservative agreement (rough consensus is not good enough) on whether we should care about a particular patent or not. Input to that community evaluation process may be documentation of legal actions taken by a patent owner. Sometimes that may happen only after a document has been published. I would support down-grading standards track documents that later turn out to be patent-infected to informational. Doing so would avoid sending a message that the IETF supports patented technology, when the IETF community didn't know about the patents at publication time. For credibility of the process, I believe it is important that these decisions are only made based on publicly available information. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
At 11:50 AM -0500 3/29/07, Mark Brown wrote: I have experienced some surprises when mixing law and Internet standards. To try to avoid surprises, I have hired IPR attorneys at two different firms to review my draft which proposes a royalty-free license grant. I expect any resulting license will be conditioned upon IETF acceptance of TLS authz as a standard. I hope to have concluded these services next week. You may feel that this is an offer, but it is in fact a form of bargaining. If you put this on standards track, then we will (or might) give a royalty-free license. That is a poor bargain for the IETF, and the IETF should not consider the offer when it decides whether or not to make the protocol a standard. This protocol extension does not seem significant enough for the IETF to be making bargains, particularly when the IPR holder has not shown good faith in the past about being up-front about what they know. A reasonable way forward would be to simply publish it as an Informational RFC as if it had been brought to the RFC Editor as an individual submission. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
--On Friday, 30 March, 2007 10:12 -0700 Paul Hoffman [EMAIL PROTECTED] wrote: At 11:50 AM -0500 3/29/07, Mark Brown wrote: I have experienced some surprises when mixing law and Internet standards. To try to avoid surprises, I have hired IPR attorneys at two different firms to review my draft which proposes a royalty-free license grant. I expect any resulting license will be conditioned upon IETF acceptance of TLS authz as a standard. I hope to have concluded these services next week. You may feel that this is an offer, but it is in fact a form of bargaining. If you put this on standards track, then we will (or might) give a royalty-free license. That is a poor bargain for the IETF, and the IETF should not consider the offer when it decides whether or not to make the protocol a standard. This protocol extension does not seem significant enough for the IETF to be making bargains, particularly when the IPR holder has not shown good faith in the past about being up-front about what they know. A reasonable way forward would be to simply publish it as an Informational RFC as if it had been brought to the RFC Editor as an individual submission. For whatever it is worth, I think we need to step carefully around the distinction Paul makes above: there are almost certainly circumstances in which we should accept a broader grant of rights conditional on standardization and a narrower one if the technology is not standardized. I wish the IPR WG were paying a bit more attention to this sort of issue. However, in this particular case, I tend to agree with Paul. While I'd be happy to hear the opinion of the TLS WG on the subject, I don't think the case has yet been made that these extensions are sufficiently important that the IETF should standardize an encumbered technology --or engage in a negotiation about those encumbrances, especially with parties who appear to have been less forthcoming in the past than our rules require. I also do not believe that it is appropriate to view Informational publication as some sort of consolation prize. If the community, and the IESG, conclude that the document and its technology should be standardized, then Informational publication should not be automatic: the document should be reviewed for sponsorship appropriateness according the IESG's recently-published procedures or actually handed off to the RFC Editor as an independent submission. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Just following onto John's note. For whatever it is worth, I think we need to step carefully around the distinction Paul makes above: there are almost certainly circumstances in which we should accept a broader grant of rights conditional on standardization and a narrower one if the technology is not standardized. I wish the IPR WG were paying a bit more attention to this sort of issue. Again, for whatever it is worth, these two-level statements have been fairly common in IPR disclosures in the past. I didn't scan the 600 or so disclosures this afternoon, but in the most recent ID-specific disclosures, this seems to be more common than not (see https://datatracker.ietf.org/public/ipr_list.cgi to check my math). I wonder from time to time how these conditional grants are supposed to interact with prototype implementations before a standard is approved (... and running code), but if I sit very still, that thought usually goes away. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Friday, March 30, 2007 10:12:14 AM -0700 Paul Hoffman [EMAIL PROTECTED] wrote: At 11:50 AM -0500 3/29/07, Mark Brown wrote: I have experienced some surprises when mixing law and Internet standards. To try to avoid surprises, I have hired IPR attorneys at two different firms to review my draft which proposes a royalty-free license grant. I expect any resulting license will be conditioned upon IETF acceptance of TLS authz as a standard. I hope to have concluded these services next week. You may feel that this is an offer, but it is in fact a form of bargaining. If you put this on standards track, then we will (or might) give a royalty-free license. That is a poor bargain for the IETF, and the IETF should not consider the offer when it decides whether or not to make the protocol a standard. I think there is a significant exception which may apply in this case. If the IPR issues are the sole remaining factor in the IETF's decision as to whether to make a protocol a standard, then I think it is entirely reasonable for the IETF to consider an offer which would eliminate or at least mitigate those issues if the protocol were to become a standard. I see nothing wrong with saying I'm willing to grant a reasonable license if my technology becomes a standard, but reserve the right to make money otherwise, as long as the IETF does not allow such an offer to result in adoption as a standard of something it would not have standardized otherwise. As for informational vs an independent submission, I think there is a factor to be considered. It seems to me that an informational IETF document is a fine way to say this is a good idea, and we think this is the right way to do FOO, but we can't actually recommend it (for whatever reason). For example, we have at least one document that defines the use of elliptic curve cryptography with one of our protocols, which is informational because the working group that produced it didn't feel they could recommend it as a standard due to the hairy IPR issues surrounding that technology. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
John == John C Klensin [EMAIL PROTECTED] writes: John I also do not believe that it is appropriate to view John Informational publication as some sort of consolation prize. John If the community, and the IESG, conclude that the document John and its technology should be standardized, then John Informational publication should not be automatic: the John document should be reviewed for sponsorship appropriateness John according the IESG's recently-published procedures or John actually handed off to the RFC Editor as an independent John submission. I agree with John here. I've basically concluded that I'm not interested in sponsoring this document as an informational or experimental document. I feel that it would come across way too much as a consolation prise and I'm not sure that it would be justified. If the IETF decides it is appropriate I'm happy to continue my sponsorship on the standards track. Note that the decision of whether I sponsor a document is one I get to make; it is not subject to community consensus. I would not object to an independent submission and while I think I would advise other ADs against sponsoring info/experimental, I would not hold a discuss if they chose to do so. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Folks, we didn't get a lot of support expressed in the second last call. If I were making a consensus call today I'd say we do not have consensus to publish draft-housley-tls-authz-extns as a proposed standard given the IPR claims against it. However Russ pointed out to me that it may be that people thought this was a typical last call where silence meant agreement. I think even under that interpretation things look grim: silence means agreement with the prevailing expressed opinion. But to make absolutely sure I propose to conduct a last call to confirm that we don't have consensus to publish as a proposed standard. Does this seem like the right approach to folks? I plan to take some next step within the next couple of days based on input. I'm sorry this issue is taking up so much of the community's time. Sam Hartman Security Area Director ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
I don't care strongly about the standards track status. However, speaking as implementer of the protocol: If the document ends up as informational or experimental, I request that we make an exception and allow the protocol to use the already allocated IANA protocol constants. That will avoid interoperability problems. I know the numbers are allocated from the pool of numbers reserved for standards track documents. There is no indication that we are running out of numbers in that registry. Thus, given the recall, I think the IETF should be flexible and not re-assign the IANA allocated numbers at this point just because of procedural reasons. /Simon Sam Hartman [EMAIL PROTECTED] writes: Folks, we didn't get a lot of support expressed in the second last call. If I were making a consensus call today I'd say we do not have consensus to publish draft-housley-tls-authz-extns as a proposed standard given the IPR claims against it. However Russ pointed out to me that it may be that people thought this was a typical last call where silence meant agreement. I think even under that interpretation things look grim: silence means agreement with the prevailing expressed opinion. But to make absolutely sure I propose to conduct a last call to confirm that we don't have consensus to publish as a proposed standard. Does this seem like the right approach to folks? I plan to take some next step within the next couple of days based on input. I'm sorry this issue is taking up so much of the community's time. Sam Hartman Security Area Director ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Sam Hartman wrote: I propose to conduct a last call to confirm that we don't have consensus to publish as a proposed standard. Does this seem like the right approach to folks? Did that ever happen before ? A Last Call trying to get consensus that there's no consensus. If silence means agreement my silence about the Last Call for say the channels bindings only indicates my agreement that I have not understood its implications for SASL. Now I wonder what my silence wrt to your proposed Last Call could mean. Agree to IANAL would be fine with me. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Simon == Simon Josefsson [EMAIL PROTECTED] writes: Simon I don't care strongly about the standards track status. Simon However, speaking as implementer of the protocol: If the Simon document ends up as informational or experimental, I Simon request that we make an exception and allow the protocol to Simon use the already allocated IANA protocol constants. That Simon will avoid interoperability problems. I know the numbers Simon are allocated from the pool of numbers reserved for Simon standards track documents. There is no indication that we Simon are running out of numbers in that registry. Thus, given Simon the recall, I think the IETF should be flexible and not Simon re-assign the IANA allocated numbers at this point just Simon because of procedural reasons. Would you support publication on the standards track given the IPR situation as someone who has implemented? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Thu Mar 29 15:39:07 2007, Frank Ellermann wrote: Sam Hartman wrote: I propose to conduct a last call to confirm that we don't have consensus to publish as a proposed standard. Does this seem like the right approach to folks? Did that ever happen before ? A Last Call trying to get consensus that there's no consensus. Well, it's a call to establish that there is consensus not to publish as a proposed standard, if you prefer a slightly less confusing phrasing. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
I think that the current texts would merit some additional work. In particular to permit authorisation statements and to clarify that how which client acts as a proxy for someone else. I mentioned the first part to the authors some time ago, but they didn't buy the idea. Sam Hartman wrote: Folks, we didn't get a lot of support expressed in the second last call. If I were making a consensus call today I'd say we do not have consensus to publish draft-housley-tls-authz-extns as a proposed standard given the IPR claims against it. However Russ pointed out to me that it may be that people thought this was a typical last call where silence meant agreement. I think even under that interpretation things look grim: silence means agreement with the prevailing expressed opinion. But to make absolutely sure I propose to conduct a last call to confirm that we don't have consensus to publish as a proposed standard. Does this seem like the right approach to folks? I plan to take some next step within the next couple of days based on input. I'm sorry this issue is taking up so much of the community's time. Sam Hartman Security Area Director ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Sam Hartman [EMAIL PROTECTED] writes: Simon == Simon Josefsson [EMAIL PROTECTED] writes: Simon I don't care strongly about the standards track status. Simon However, speaking as implementer of the protocol: If the Simon document ends up as informational or experimental, I Simon request that we make an exception and allow the protocol to Simon use the already allocated IANA protocol constants. That Simon will avoid interoperability problems. I know the numbers Simon are allocated from the pool of numbers reserved for Simon standards track documents. There is no indication that we Simon are running out of numbers in that registry. Thus, given Simon the recall, I think the IETF should be flexible and not Simon re-assign the IANA allocated numbers at this point just Simon because of procedural reasons. Would you support publication on the standards track given the IPR situation as someone who has implemented? If the patent concern is valid and covers TLS libraries or other applications, no. However, as far as I am aware of the public information that is available, the situation appears to be that we don't know whether these patents apply and to what extent. I don't know whether the patents were filed in good or bad faith. More information from the patent holders may help here. If it is possible to implement the protocol without violating the patents, I would support publication. I've seen some claims that this may be possible. I have no interest in reading these patents myself, but my position would be influenced if someone knowledgeable reads the patents. Given the amount of patents out there, it would be unreasonable for us to move everything to informational just because someone finds something that may be relevant to a piece of work. The community needs to evaluate patent claims, and preferably reach conservative agreement (rough consensus is not good enough) on whether we should care about a particular patent or not. Input to that community evaluation process may be documentation of legal actions taken by a patent owner. Sometimes that may happen only after a document has been published. I would support down-grading standards track documents that later turn out to be patent-infected to informational. Doing so would avoid sending a message that the IETF supports patented technology, when the IETF community didn't know about the patents at publication time. For credibility of the process, I believe it is important that these decisions are only made based on publicly available information. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
At 10:06 AM -0400 3/29/07, Sam Hartman wrote: Folks, we didn't get a lot of support expressed in the second last call. If I were making a consensus call today I'd say we do not have consensus to publish draft-housley-tls-authz-extns as a proposed standard given the IPR claims against it. However Russ pointed out to me that it may be that people thought this was a typical last call where silence meant agreement. I think even under that interpretation things look grim: silence means agreement with the prevailing expressed opinion. But to make absolutely sure I propose to conduct a last call to confirm that we don't have consensus to publish as a proposed standard. Does this seem like the right approach to folks? I plan to take some next step within the next couple of days based on input. I'm sorry this issue is taking up so much of the community's time. I thought Eric Rescorla and Pasi Eronen had suggested that this document be evaluated by the TLS working group and the IPR terms evaluated there. I have that suggestion in an email thread on the main IETF list, started by Eric and with the thread title Last Call Comments on draft-housley-tls-authz-07. I personally believe that would be a sensible way forward, as it seems likely that the working group would be better able to evaluate the impact of the IPR claims (both RedPhone's and IBM's) than the main IETF list. Was there a problem that came up with that way forward in Prauge? regards, Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Ted == Ted Hardie [EMAIL PROTECTED] writes: Ted I thought Eric Rescorla and Pasi Eronen had suggested that Ted this document be evaluated by the TLS working group and the Ted IPR terms evaluated there. I have that suggestion in an Ted email thread on the main IETF list, started by Eric and with Ted the thread title Last Call Comments on Ted draft-housley-tls-authz-07. I personally believe that would Ted be a sensible way forward, as it seems likely that the Ted working group would be better able to evaluate the impact of Ted the IPR claims (both RedPhone's and IBM's) than the main IETF Ted list. The problem is that this work is outside the charter of the TLS working group. So, I don't think asking them to take on the document would be appropriate. I also don't think rechartering TLS for this purpose would be appropriate. If there is a question we can ask that does not involve them taking on responsibility for the technical details of the work then I'd be happy to take that path forward. It's important in writing such a question not to ask them to make a consensus determination about the IPR claims as the IETf doesn't do that, but rather to focus on the document given the IPR claims. I don't know how to do that without asking them to take on the document as a whole. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
At 1:05 PM -0400 3/29/07, Sam Hartman wrote: The problem is that this work is outside the charter of the TLS working group. So, I don't think asking them to take on the document would be appropriate. I also don't think rechartering TLS for this purpose would be appropriate. It is actually fairly common for working groups to provide advice to the community on work that is related to their charter and not on it. If you do not wish to amend the TLS charter, you can make a positive evaluation by TLS a necessary step before you agree to sponsor this document; since that would not make the draft a work product of the working group, I don't think that would require a full re-charter. A re-charter would allow you, obviously, to move change control into the WG and allow competing proposals to be put forward. That might be useful at this point, but it also doesn't seem required. Basically, I think this has moved to the stage where evaluation by a community of developers and potential licensees is the best way forward. The review by the IETF community as a whole does not seem to be providing this. You can, of course, just drop it as a result. But if you are concerned to get a more realistic up/down evaluation, then having TLS do the evaluation or chartering some WG to do the work seem to be the obvious choices. Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Thu, 29 Mar 2007 17:12:18 +0200 Simon Josefsson [EMAIL PROTECTED] wrote: The community needs to evaluate patent claims, and preferably reach conservative agreement (rough consensus is not good enough) on whether we should care about a particular patent or not. Input to that community evaluation process may be documentation of legal actions taken by a patent owner. Sometimes that may happen only after a document has been published. I would support down-grading standards track documents that later turn out to be patent-infected to informational. Doing so would avoid sending a message that the IETF supports patented technology, when the IETF community didn't know about the patents at publication time. For credibility of the process, I believe it is important that these decisions are only made based on publicly available information. To be consistent with IETF process and IPR policy, I think that the only way to do that is via a standards action -- an IETF consensus call (often preceeded by a WG discussion and last call) to downgrade the document. Reclassifying documents as Historic is done by separate RFCs -- I suspect that that's the mechanism that would have to be followed here. Look at it this way -- we give WGs the right to standardize encumbered technologies. If we're to later reject technologies because they've become encumbered, it's really a case of going through the same sort of decision process. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Ted == Ted Hardie [EMAIL PROTECTED] writes: Ted At 1:05 PM -0400 3/29/07, Sam Hartman wrote: The problem is that this work is outside the charter of the TLS working group. So, I don't think asking them to take on the document would be appropriate. I also don't think rechartering TLS for this purpose would be appropriate. Ted It is actually fairly common for working groups to provide Ted advice to the community on work that is related to their Ted charter and not on it. If you do not wish to amend the TLS Ted charter, you can make a positive evaluation by TLS a Ted necessary step before you agree to sponsor this document; Ted since that would not make the draft a work product of the Ted working group, I don't think that would require a full Ted re-charter. A re-charter would allow you, obviously, to move Ted change control into the WG and allow competing proposals to Ted be put forward. That might be useful at this point, but it Ted also doesn't seem required. Ted, I'd like to do this. However I could use some help figuring out exactly what question I'm asking the TLS working group to provide advice on. I guess it could be as simple as Do you think draft-housley-tls-authz-extns is worth publishing on the standards track? Would that be the right direction? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
At 4:25 PM -0400 3/29/07, Sam Hartman wrote: Ted, I'd like to do this. However I could use some help figuring out exactly what question I'm asking the TLS working group to provide advice on. I guess it could be as simple as Do you think draft-housley-tls-authz-extns is worth publishing on the standards track? That sounds fine to me. You could load it up with other questions (about the IANA considerations, the IPR issues, or competing proposals), but the upshot really does come down to: You're the folks who will live with this: is it a good idea? Your formulation captures that well enough, in my opinion. regards, Ted Would that be the right direction? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Ted == Ted Hardie [EMAIL PROTECTED] writes: Ted At 4:25 PM -0400 3/29/07, Sam Hartman wrote: Ted, I'd like to do this. However I could use some help figuring out exactly what question I'm asking the TLS working group to provide advice on. I guess it could be as simple as Do you think draft-housley-tls-authz-extns is worth publishing on the standards track? Ted That sounds fine to me. You could load it up with other Ted questions (about the IANA considerations, the IPR issues, or Ted competing proposals), but the upshot really does come down Ted to: You're the folks who will live with this: is it a good Ted idea? Your formulation captures that well enough, in my Ted opinion. regards, Ted OK. Then my current best thing to do is to send the question above to the TLS working group. The authors have indicated they may ask me for a delay and if they do I'll honor that. This seems far better than a third last call to confirm lack of consensus. Thanks for your help. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Tuesday 27 February 2007 08:53, IESG Secretary wrote: The IESG is considering re-approving this draft with knowledge of the IPR disclosure from Redphone Security. The IESG solicits final comments on whether the IETF community has consensus to publish draft-housley-tls-authz-extns as a proposed standard given the IPR claimed. I believe that approval of draft-houselye-tls-authz-extns would be the wrong decision, for the following reasons: 1. It would send the wrong message to other companies to both Redphone Security and other companies who would seek to engage in similar practice. This is not to suggest that any particular company did or would seek to do so, just that the IETF should seek to deter this behaviour. 2. The authorisation extensions have recently been implemented by a free software library, and problems were found in a couple of area. http://www1.ietf.org/mail-archive/web/tls/current/msg01518.html Approval of draft-housley-tls-authz-extns given current knowledge would be a poor decision both politically and technically. Brad pgp9hiyDTvsxd.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Eric Rescorla has agreed to deal with the third party disclosure on my behalf. thanks for all the volunteers of help. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Folks, in addition to the IPR disclosure that triggered this second last call, I've received mail from an interested party that IPR held by a third party who as far as we know was not involved in IETF discussions of this draft may apply to the draft. While the interested party was willing to bring it to my attention, they did not want to go through the hassle of filing a third party IPR disclosure. It's clear that in my role as shepherding AD I should not take any position on whether the IPR covers this draft. I asked the IESG what I should do and people thought that I was clearly obligated to file a third party IPR disclosure making it clear that while I as an IESG member took no position, I wanted the community to look at the IPR and evaluate it. Unfortunately, the document I have is a PDF of a scanned set of images. I don't have a good way to read it enough to even pull out the title of the patent application. Would someone be willing to take on the task of taking this PDF and filing a third party disclosure? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On June 27, 2006, the IESG approved Transport Layer Security (TLS) Authorization Extensions, (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. The disclosure can be found at https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=767 . The disclosure may cover technology in draft-housley-tls-authz-extns and other drafts. The claimed IPR relates to a US patent application filed September 23, 2005. The claims of this application are now public so IETF participants may examine the claims. According to section 3.2.1 of RFC 3979, The Contributor represents that he or she has made or will promptly make all disclosures required by Section 6.1.1 of this document. Section 6.1.1 requires: Any Contributor who reasonably and personally knows of IPR meeting the conditions of Section 6.6 which the Contributor believes Covers or may ultimately Cover his or her Contribution, or which the Contributor reasonably and personally knows his or her employer or sponsor may assert against Implementing Technologies based on such Contribution, must make a disclosure in accordance with this Section 6. The IESG has been informed by Mark Brown that he had knowledge of the September 2005 patent application filed by his employer at the time he submitted draft-housley-tls-authz-extns. Accordingly, he was obligated to disclose the existence of this patent application upon making this submission. Making a required IPR disclosure after a draft is approved does not meet the requirement to promptly make the disclosure. According to section 7 of RFC 3979 failure to make a required disclosure is a failure of process. It should be noted that the above disclosure obligations apply to unpublished patent applications. When a patent application that is required to be disclosed is unpublished, the discloser must 'indicate that the claim is based on unpublished patent applications', but is not required to list the application number (see RFC 3978 Section 6.4.1). the IESG withdraws its approval of draft-housley-tls-authz-extns. The RFC editor is hereby requested to remove this draft from their publication queue. IANA is hereby requested to remove the assignments for this draft and mark the codepoints as reserved. Should this draft be approved in the future, IANA is requested to re-assign the same codepoints. The IESG is considering re-approving this draft with knowledge of the IPR disclosure from Redphone Security. The IESG solicits final comments on whether the IETF community has consensus to publish draft-housley-tls-authz-extns as a proposed standard given the IPR claimed. Comments can be sent to ietf@ietf.org or exceptionally to [EMAIL PROTECTED] Comments should be sent by 2007-03-13. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
