Simon Josefsson wrote: > I disagree. The IETF policies around patents mention "use" as well > as "implementation". Thus, a license that permit "implementation" > but not permitting "use" should generate similar scrutiny and > discussion. It poses the same problem for actual users. > > I strongly disagree with a notion that just because someone grants a > patent license for "implementation" that the IETF community has to > consider the patent situation around the technology as irrelevant. > Use of technology goes beyond "implementation". This is > acknowledged in the IETF policy documents. Compare, e.g., RFC 3979 > and in particular the definition of the term "Covers". > > I also disagree with the claim that the draft is unencumbered. I > don't follow how you reach that conclusion from the patent > disclaimer. You quoted only one paragraph out of several, and the > other paragraphs are the ones that encumber use of the protocol. It > may be your interpretation that the draft is unencumbered, but > everyone get the same opportunity to make their own interpretation. > As implementer of the technology, and having consulted with legal > aid, I have made another interpretation. <speaking as an individual, not wearing any hats> Well, it's good to remember that there are *lots* of patents about larger systems that include IETF protocols (e.g., TLS, HTTP, MPLS, Mobile IP, or RADIUS) as components. What's claimed to be novel (and covered by the patent) is not the IETF protocol as such, but the combination: using the protocol(s) in certain environment in particular way to solve something. And of course there are lots of implementation technique patents where what's claimed to be novel (and covered by the patent) is some particular way of implementing the protocols (e.g. better performance than "obvious" implementations). Usually these types of patents are *not* disclosed to the IETF, since the protocol as such is not covered by the patent. In fact, my guess would be that we probably don't have *any* IETF protocols where someone has not patented using protocol A in bigger system B in way C to solve D (where B+C+D is something that the RFC did not describe, so it could be non-obvious and novel). If we required that IETF protocols must not have any such "field of use restrictions" (where using the protocol in certain way could be encumbered), we would not publish any protocols at all. My reading of RedPhone's IPR disclosure 1026 is that they claim to have a patent application about a larger system that includes tls-authz as one part, and uses it in particular way. If you want to build a system matching the numbered list 1..4 in the disclosure (RedPhone's description of what they claim is covered), then you would have to consider this IPR disclosure. However, I think there are many more good uses for tls-authz that do *not* match items 1..4. Just because someone has filed a patent application on some rather obscure combination of B+C+D should not prevent others from using the protocol for things not covered by that application. Thus, I support publishing this as an RFC (either Informational or Standards Track). (BTW, I think it's pretty clear that RedPhone didn't get the process right here. Some have claimed they did this knowingly with malicious intent, others have attributed it more to carelessness and ignorance -- I would say we can't really know without doing a Vulcan mind meld :-) Either way, I think we should consider the draft's technical merits and IPR situation *now*, and not put too much weight on the history.) Best regards, Pasi _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf