Re: Fwd: Security Assessment of the Transmission Control Protocol (TCP)
Keith Moore wrote: > Marshall Eubanks wrote: >> If I am reading this correctly the UK Centre for the Protection of >> National Infrastructure >> wants the IETF (or some other body) to produce a "companion document to >> the IETF specifications that discusses the security aspects and >> implications of the protocols, identifies the existing vulnerabilities, >> discusses the possible countermeasures, and analyses their respective >> effectiveness." > > It's difficult to imagine that these things could be adequately captured > in a static document, for TCP or any other protocol, because new threats > and countermeasures continue to be identified decades after the base > protocol is well-settled. Maybe something like an expanded version of > the RFC Editor's errata pages would be more appropriate? One might imagine an informational document which was routinely obsoleted by future iterations. Keeping it tractable is a product of necessarily limiting the scope. > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: References to Redphone's "patent"
> > Shall we ask the FSF members of IETF also to comment on the > need for IETF to > develop a comprehensive policy toward patents so that encumbrances to > Internet standards can be understood and avoided in the future? > > /Larry IETF does have a patent policy. It is at RFC 3979. It may not be to everyone's liking, but it does exist. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: Security Assessment of the Transmission Control Protocol (TCP)
Marshall Eubanks wrote: > If I am reading this correctly the UK Centre for the Protection of > National Infrastructure > wants the IETF (or some other body) to produce a "companion document to > the IETF specifications that discusses the security aspects and > implications of the protocols, identifies the existing vulnerabilities, > discusses the possible countermeasures, and analyses their respective > effectiveness." It's difficult to imagine that these things could be adequately captured in a static document, for TCP or any other protocol, because new threats and countermeasures continue to be identified decades after the base protocol is well-settled. Maybe something like an expanded version of the RFC Editor's errata pages would be more appropriate? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How we got here, RE: References to Redphone's "patent"
I'll also add that we have now many working groups closing in on their ten-year anniversary, with a dozen RFCs to their credit. (DHC and AVT are probably among the oldest, but there are many others not far behind. AVT has about 90 RFCs listed.) I don't see how one can create a model that predicts the future that far ahead, and can be readily applicable across the range of items being specified. What's appropriate for a base spec may not be appropriate or necessary for a special-purpose extension. Whether this WG model is a good one is another question, but it would seem peculiar to have the IPR model dictate how WGs are run in practice. (I suspect the pragmatic outcome would be that, say, RAI would have one WG for each IPR flavor...) Also, most of the IPR these days seems to be filed by third parties, other than the I-D authors, often long after the I-D has been accepted as a WG item. (I think it would be interesting to do some statistics on who actually does the filing and at what stage of the I-D.) It would also be interesting to know whether any RFC author company has actually sued somebody for patent infringement, vs. the dozens of suits where third parties are involved. By now, we should have a fair amount of empirical data to know where the real threats are. Henning On Feb 13, 2009, at 6:40 PM, Brian E Carpenter wrote: Phill, On 2009-02-14 10:41, Hallam-Baker, Phillip wrote: ... The proposal that I made then was that when a working group is started, it specify the IPR criteria under which it is chartered. In some cases it makes perfect sense to charter a group that will be using encumbered technology. In other cases the entire purpose of the group requires that any technology be open and unencumbered. We've been round that argument enough times that it's become a tradition. A priori rules like that make no sense for the IETF. 1. They inhibit innovative thinking within the WG process, because they mean that the major technical options must basically be decided before you start, so that you can decide which IPR regime is going to work. And if you decide a priori to be RF, the available solutions are dramatically constrained. Or to say it more emotively: all the good ideas have been patented anyway. 2. They would assist the patent trolls, who could make sure to quietly acquire patents that encumber the 'royalty free' solution just in time for the standard to be widely adopted. Leaving the choice until later in the process isn't perfect, but it reduces these two risks and matches the reality of IPR laws and practices, which are heavily based on RAND and reciprocity, like it or not. IMHO, as always. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: How we got here, RE: References to Redphone's "patent"
In my view major technical options should be decided before you start. This is a standards process, not an invention process. I do not design protocols in committee, never have, never will. That type of work was possible when there were 40 people coming to IETF meetings and the problem was coordinating independent research projects. It is not a sensible use of people's time to do the type of unconstrained investigation you suggest with more than five people in the room. Understanding the cost of the materials you intend to use is a key part of being an engineer. I like to work from price on the page catalogs. If a supplier wants to play 'guess my price' then I look to do the job another way. What you suggest increases the leverage of patent trolls. The more working group effort is sunk into the idea that they claim proprietary ownership of, the more leverage they have. Moreover nobody can implement until the IPR issues are fully understood. -Original Message- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Fri 2/13/2009 6:40 PM To: Hallam-Baker, Phillip Cc: ietf@ietf.org Subject: Re: How we got here, RE: References to Redphone's "patent" Phill, On 2009-02-14 10:41, Hallam-Baker, Phillip wrote: ... > The proposal that I made then was that when a working group is started, it > specify the IPR criteria under which it is chartered. In some cases it makes > perfect sense to charter a group that will be using encumbered technology. In > other cases the entire purpose of the group requires that any technology be > open and unencumbered. We've been round that argument enough times that it's become a tradition. A priori rules like that make no sense for the IETF. 1. They inhibit innovative thinking within the WG process, because they mean that the major technical options must basically be decided before you start, so that you can decide which IPR regime is going to work. And if you decide a priori to be RF, the available solutions are dramatically constrained. Or to say it more emotively: all the good ideas have been patented anyway. 2. They would assist the patent trolls, who could make sure to quietly acquire patents that encumber the 'royalty free' solution just in time for the standard to be widely adopted. Leaving the choice until later in the process isn't perfect, but it reduces these two risks and matches the reality of IPR laws and practices, which are heavily based on RAND and reciprocity, like it or not. IMHO, as always. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How we got here, RE: References to Redphone's "patent"
Phill, On 2009-02-14 10:41, Hallam-Baker, Phillip wrote: ... > The proposal that I made then was that when a working group is started, it > specify the IPR criteria under which it is chartered. In some cases it makes > perfect sense to charter a group that will be using encumbered technology. In > other cases the entire purpose of the group requires that any technology be > open and unencumbered. We've been round that argument enough times that it's become a tradition. A priori rules like that make no sense for the IETF. 1. They inhibit innovative thinking within the WG process, because they mean that the major technical options must basically be decided before you start, so that you can decide which IPR regime is going to work. And if you decide a priori to be RF, the available solutions are dramatically constrained. Or to say it more emotively: all the good ideas have been patented anyway. 2. They would assist the patent trolls, who could make sure to quietly acquire patents that encumber the 'royalty free' solution just in time for the standard to be widely adopted. Leaving the choice until later in the process isn't perfect, but it reduces these two risks and matches the reality of IPR laws and practices, which are heavily based on RAND and reciprocity, like it or not. IMHO, as always. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fwd: Security Assessment of the Transmission Control Protocol (TCP)
If I am reading this correctly the UK Centre for the Protection of National Infrastructure wants the IETF (or some other body) to produce a "companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the existing vulnerabilities, discusses the possible countermeasures, and analyses their respective effectiveness." Regards Marshall Begin forwarded message: From: Fernando Gont Date: February 12, 2009 5:38:35 PM EST To: bugt...@securityfocus.com, full-disclos...@lists.grok.org.uk Subject: Security Assessment of the Transmission Control Protocol (TCP) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, folks, The United Kingdom's Centre for the Protection of National Infrastructure has just released the document "Security Assessment of the Transmission Control Protocol (TCP)", on which I have had the pleasure to work during the last few years. The motivation to produce this document is explained in the Preface of the document as follows: - cut here The TCP/IP protocol suite was conceived in an environment that was quite different from the hostile environment they currently operate in. However, the effectiveness of the protocols led to their early adoption in production environments, to the point that to some extent, the current world?s economy depends on them. While many textbooks and articles have created the myth that the Internet protocols were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify, and overlook their security implications. While the Internet technology evolved since it early inception, the Internet?s building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years, many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some of them were based on flaws in some protocol implementations, affecting only a reduced number of systems, while others were based in flaws in the protocols themselves, affecting virtually every existing implementation. Even in the last couple of years, researchers were still working on security problems in the core protocols. The discovery of vulnerabilities in the TCP/IP protocol suite usually led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats and the best mitigations known at the time the reports were published. Unfortunately, this also led to the documentation of the discovered protocol vulnerabilities being spread among a large number of documents, which are sometimes difficult to identify. For some reason, much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force). This basically led to a situation in which ?known? security problems have not always been addressed by all vendors. In addition, in many cases vendors have implemented quick ?fixes? to the identified vulnerabilities without a careful analysis of their effectiveness and their impact on interoperability. Producing a secure TCP/IP implementation nowadays is a very difficult task, in part because of the lack of a single document that serves as a security roadmap for the protocols. Implementers are faced with the hard task of identifying relevant documentation and differentiating between that which provides correct advice, and that which provides misleading advice based on inaccurate or wrong assumptions. There is a clear need for a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the existing vulnerabilities, discusses the possible countermeasures, and analyses their respective effectiveness. This document is the result of a security assessment of the IETF specifications of the Transmission Control Protocol (TCP), from a security point of view. Possible threats are identified and, where possible, countermeasures are proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. This document does not aim to be the final word on the security aspects of TCP. On the contrary, it aims to raise awareness about a number of TCP vulnerabilities that have been faced in the past, those that are currently being faced, and some of those that we may still have to deal with in the future. Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new vulnerabilities are discovered. -
Re: References to Redphone's "patent"
> From: Thomas Narten > IPR consultation is all about risk analysis. And risk to the IETF vs. > risk to me personally vs. risk to my employer vs. risk to somebody > else's employer, etc. All are VERY different things. > ... It will still come down to someone else trying to tell *me* (or > you) that I (or you) shouldn't worry about something ... I am aware of all that (just as I am aware that until the judge/jury have their say, advice from an attorney is just that, advice). What that says to me is that anything from an IPR consulting board would have to carry appropriate warning boilerplate about these sorts of issues. Still, I think a lot of people in the IETF would find the professional opinions of a competent expert _useful data_. Bearing in mind the complexities of patent legalese, etc, etc, even having someone say 'this is what IMO the claims mean, in English' would probaly be useful to a lot of people. (Lord knows I find claims incomprehensible sometimes without a lot of study - and I've been an expert witness in several patent suits!) Even having their interpretation in front of you would probably be a substantial help if/when you try and read the patent/filing yourself. And there are all sorts of other useful data a patent attorney could offer. To take but one example, Thierry Moreau's revelations today that for the RedPhone application, a PCT/WIPO examination report denies novelty to all claims but three is most interesting - but I would have no idea how to find such things, if in fact I even knew they existed, and could be looked for. (Which I didn't - and I have done an international patent, albeit some years ago now!) Also, most people involved in a business think it prudent to consult with an attorney to gain detailed advice on legal issues that pertain to their business dealings - why does the IETF think it has no need of similar expert advice? Yes, any such advice has limits, but is no advice really better than advice with limits? (And in passing, anyone who has consulted extensively with attorneys in business matters eventually understands that all the attorney can really do is offer advice - in the end, someone else has to make the decision, because turning over decision-making to the attorneys is usually not fruitful.) To put it another way, experts have expertise in various fields, and it's unwise to ignore expertise. You and I would think a lawyer who tried to design a network, without asking advice from a network engineer, to be acting unwisely, and to try and deal with _legal_ issues, without advice from a _legal expert_, is to me equally unwise. > This is fundamentally an individual decision that every implementor > needs to make on their own. Implentors will of course need to make their own individual decisions - but again, anyone so making such decisions would be well-advised to either i) consult an attorney, or ii) be associated with an organization that did it for them. Since a lot of people, especially lone implementors, aren't in a position to do i), even an imperfect form of ii) (i.e. reading legal analysis provided by expert contributors in the IETF, at the time the standard was drafted) is IMO better than being thrown into the deep end without knowing how to swim in legalese. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Changes needed to Last Call boilerplate
On Thu, Feb 12, 2009 at 3:31 PM, Noel Chiappa wrote: > I've heard from a number of the FSF thundering herd people to the effect of > 'but the announcement says send email to ietf@ietf.org". (They're > conveniently ignoring the fact that it says "the IETF community" all over > the > place in the Last Call, but never mind.) > > So clearly we need to change it to say something like: For the record, I strongly oppose this change. The problem seems neither very common nor very serious, and the "solution" seems unduly complex and likely to result in unintended side-effects. -Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Fwd: Re: Changes needed to Last Call boilerplate]
--On Friday, February 13, 2009 17:40 +0200 Jari Arkko wrote: >... > I don't have a problem with the number of messages. Deleting > is easy. But I wouldn't mind stricter enforcement of the > Subject lines... >... If you wanted something that would work as well or better than Subject lines, and that would actually make things easier if, as is periodically the case, the discussion of a particular document diverges into different subthreads, consider using subaddresses that are different for, and unique to, each Last Call. Subaddresses are not as widely used and supported on the net as some of us think they should be. However, the usual comments about dogfood-eating apply as, perhaps, does the observation that anyone without sufficient clues to send a message to a mailbox that uses a subaddress may be someone we, in fact, don't need to hear from. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: References to Redphone's "patent"
No, please do not go there. You do not want negotiating flexibility in this type of situation. Instead of looking how to arrive at a deal, the IETF needs to think about structuring the incentives so that there is no gain for a patent troll. -Original Message- From: ietf-boun...@ietf.org on behalf of Thomas Narten Sent: Fri 2/13/2009 3:30 PM To: Noel Chiappa Cc: ietf@ietf.org Subject: Re: References to Redphone's "patent" j...@mercury.lcs.mit.edu (Noel Chiappa) writes: > > From: "Lawrence Rosen" > > the previous IPR WG .. refused even to discuss a patent policy for IETF. > I thought the IETF sort of had one, though (see RFC mumble)? > I definitely agree that the IETF could use some sort of permanent > legal IPR consulting board that WG's could go to and say 'we have > this IPR filing, what does it mean, and what is the likely impact on > our work'. Please don't go there. IPR consultation is all about risk analysis. And risk to the IETF vs. risk to me personally vs. risk to my employer vs. risk to somebody else's employer, etc. All are VERY different things. I don't see an IPR consulting board as being helpful at all. It will still come down to someone else trying to tell *me* (or you) that I (or you) shouldn't worry about something, yet it might well be *my* (or your) skin if things go awry. The IETF absolutely and fundamentally needs stay out of evaluating the merits of potential IPR and what the associated risks are. This is fundamentally an individual decision that every implementor needs to make on their own. This principle has been a bedrock of the IETF's IPR policy for a very long time, and for good reason. Oh, and another important point, even when we have IPR disclosures, they are often for patent applications, which are not public, nor have they been issued (so they are only potential patents). In such cases, there is precious little an advisory board could tell us, other than "we don't know"... Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
How we got here, RE: References to Redphone's "patent"
There is certainly something wrong, but the source is not necessarily the IETF. The USPTO seems to be a bigger source of the problem here. There are many problems with the current approach of leaving patent policy to groups, not least the fact that case by case negotiation on a per-working group basis is the least likely to achieve what IETF participants want. As we saw in the case of MASS, IPR holders are unlikely to make concessions in one working group unless they can expect reciprocity and that other IPR holders will be held to the same standards in other working groups. At this point we do in fact understand how to grant a right to use a patent in an open source implementation in a manner that protects the interest of the IPR holder in enforcing reciprocal rights in the standard. But at the time we did not. The concept of a cure clause only came later. There were many problems with the IETF patent process. Not least the fact that many of the participants had no idea what they were talking about. As far as I know, I was the only person to submit a proposal to that group that had a lawyer as a co-author. But that did not stop certain persons who are not lawyers and have never worked in a practices group as I have dismissing my position as being uninformed in their view. I strongly suspect that one of the reasons for the current state of the IETF IPR policy is that the only people who get sufficiently interested in it to actually attend meetings tend to be open source ideologues, representatives of large IPR holders and private consultants offering expert testimony in patent disputes. The proposal that I made then was that when a working group is started, it specify the IPR criteria under which it is chartered. In some cases it makes perfect sense to charter a group that will be using encumbered technology. In other cases the entire purpose of the group requires that any technology be open and unencumbered. I also proposed that rather than attempting to create yet another patent policy, that the IETF simply outsource the approach. In OASIS a working group specifies the IPR policy at the start and may choose either an open or a proprietary one. In W3C all groups are required to have an open policy. What that means in practice is that it is possible to have a specification that has optional extensions that are encumbered or purportedly encumbered. But it must be possible to implement the spec without using the encumbered options. Both policies are in theory vulnerable to the type of denial of standard by bogus assertion of IPR rights attack described. But in practice so are implementations. -Original Message- From: ietf-boun...@ietf.org on behalf of Lawrence Rosen Sent: Fri 2/13/2009 11:18 AM To: ietf@ietf.org Subject: References to Redphone's "patent" Lots of the recent emails on this list refer to Redphone's "patent" but there is no such thing. As anyone who has ever worked with real patents knows, there is a great difference between a patent application and a patent. Whatever claims are written in patent applications are merely wishes and hopes, placeholders for negotiated language after a detailed examination of the application. Until the PTO actually issues a patent, nothing is fixed. And even then, newly-found prior art and other issues can defeat an issued patent. Why are we all so afraid of Redphone? Who gives a damn what patent claims they hope to get? There's something wrong with the IETF process if spurious and self-serving assertions that "a patent application has been filed" can serve to hold up progress on important technology. I wish you'd ask real patent attorneys to advise the community on this rather than react with speculation and a generalized fear of patents. /Larry Lawrence Rosen Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243 Skype: LawrenceRosen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: References to Redphone's "patent"
Chuck Powers wrote: > +1 > > That is a legal quagmire that the IETF (like all good standards > development groups) must avoid. Chuck is not alone in saying that, as you have just seen. These are the very people who refused to add "patent policy" to the charter of the previous IPR WG, and who controlled "consensus" on that point last time. Shall we ask the FSF members of IETF also to comment on the need for IETF to develop a comprehensive policy toward patents so that encumbrances to Internet standards can be understood and avoided in the future? /Larry > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of > Powers Chuck-RXCP20 > Sent: Friday, February 13, 2009 12:36 PM > To: Thomas Narten; Noel Chiappa > Cc: ietf@ietf.org > Subject: RE: References to Redphone's "patent" > > +1 > > That is a legal quagmire that the IETF (like all good standards > development groups) must avoid. > > > Regards, > Chuck > - > Chuck Powers, > Motorola, Inc > phone: 512-427-7261 > mobile: 512-576-0008 > > > > -Original Message- > > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > > Behalf Of Thomas Narten > > Sent: Friday, February 13, 2009 2:31 PM > > To: Noel Chiappa > > Cc: ietf@ietf.org > > Subject: Re: References to Redphone's "patent" > > > > j...@mercury.lcs.mit.edu (Noel Chiappa) writes: > > > > > > From: "Lawrence Rosen" > > > > > > the previous IPR WG .. refused even to discuss a > > patent policy for IETF. > > > > > I thought the IETF sort of had one, though (see RFC mumble)? > > > > > I definitely agree that the IETF could use some sort of permanent > > > legal IPR consulting board that WG's could go to and say 'we have > > > this IPR filing, what does it mean, and what is the likely impact on > > > our work'. > > > > Please don't go there. > > > > IPR consultation is all about risk analysis. And risk to the IETF > > vs. risk to me personally vs. risk to my employer vs. risk to somebody > > else's employer, etc. All are VERY different things. > > > > I don't see an IPR consulting board as being helpful at all. It will > > still come down to someone else trying to tell *me* (or you) that I > > (or you) shouldn't worry about something, yet it might well be *my* > > (or your) skin if things go awry. > > > > The IETF absolutely and fundamentally needs stay out of evaluating the > > merits of potential IPR and what the associated risks are. This is > > fundamentally an individual decision that every implementor needs to > > make on their own. > > > > This principle has been a bedrock of the IETF's IPR policy for a very > > long time, and for good reason. > > > > Oh, and another important point, even when we have IPR disclosures, > > they are often for patent applications, which are not public, nor have > > they been issued (so they are only potential patents). In such cases, > > there is precious little an advisory board could tell us, other than > > "we don't know"... > > > > Thomas > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: References to Redphone's "patent"
Excerpts from Thomas Narten on Fri, Feb 13, 2009 03:30:41PM -0500: > > I definitely agree that the IETF could use some sort of permanent > > legal IPR consulting board that WG's could go to and say 'we have > > this IPR filing, what does it mean, and what is the likely impact on > > our work'. > > Please don't go there. > > IPR consultation is all about risk analysis. And risk to the IETF > vs. risk to me personally vs. risk to my employer vs. risk to somebody > else's employer, etc. All are VERY different things. We tried the idea and came to those conclusions. All the board could do would be to utter platitudes. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: References to Redphone's "patent"
+1 That is a legal quagmire that the IETF (like all good standards development groups) must avoid. Regards, Chuck - Chuck Powers, Motorola, Inc phone: 512-427-7261 mobile: 512-576-0008 > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of Thomas Narten > Sent: Friday, February 13, 2009 2:31 PM > To: Noel Chiappa > Cc: ietf@ietf.org > Subject: Re: References to Redphone's "patent" > > j...@mercury.lcs.mit.edu (Noel Chiappa) writes: > > > > From: "Lawrence Rosen" > > > > the previous IPR WG .. refused even to discuss a > patent policy for IETF. > > > I thought the IETF sort of had one, though (see RFC mumble)? > > > I definitely agree that the IETF could use some sort of permanent > > legal IPR consulting board that WG's could go to and say 'we have > > this IPR filing, what does it mean, and what is the likely impact on > > our work'. > > Please don't go there. > > IPR consultation is all about risk analysis. And risk to the IETF > vs. risk to me personally vs. risk to my employer vs. risk to somebody > else's employer, etc. All are VERY different things. > > I don't see an IPR consulting board as being helpful at all. It will > still come down to someone else trying to tell *me* (or you) that I > (or you) shouldn't worry about something, yet it might well be *my* > (or your) skin if things go awry. > > The IETF absolutely and fundamentally needs stay out of evaluating the > merits of potential IPR and what the associated risks are. This is > fundamentally an individual decision that every implementor needs to > make on their own. > > This principle has been a bedrock of the IETF's IPR policy for a very > long time, and for good reason. > > Oh, and another important point, even when we have IPR disclosures, > they are often for patent applications, which are not public, nor have > they been issued (so they are only potential patents). In such cases, > there is precious little an advisory board could tell us, other than > "we don't know"... > > Thomas > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: References to Redphone's "patent"
j...@mercury.lcs.mit.edu (Noel Chiappa) writes: > > From: "Lawrence Rosen" > > the previous IPR WG .. refused even to discuss a patent policy for IETF. > I thought the IETF sort of had one, though (see RFC mumble)? > I definitely agree that the IETF could use some sort of permanent > legal IPR consulting board that WG's could go to and say 'we have > this IPR filing, what does it mean, and what is the likely impact on > our work'. Please don't go there. IPR consultation is all about risk analysis. And risk to the IETF vs. risk to me personally vs. risk to my employer vs. risk to somebody else's employer, etc. All are VERY different things. I don't see an IPR consulting board as being helpful at all. It will still come down to someone else trying to tell *me* (or you) that I (or you) shouldn't worry about something, yet it might well be *my* (or your) skin if things go awry. The IETF absolutely and fundamentally needs stay out of evaluating the merits of potential IPR and what the associated risks are. This is fundamentally an individual decision that every implementor needs to make on their own. This principle has been a bedrock of the IETF's IPR policy for a very long time, and for good reason. Oh, and another important point, even when we have IPR disclosures, they are often for patent applications, which are not public, nor have they been issued (so they are only potential patents). In such cases, there is precious little an advisory board could tell us, other than "we don't know"... Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
On 2009-02-13 16:47, Steven M. Bellovin wrote: > On Thu, 12 Feb 2009 21:38:44 +0100 > Simon Josefsson wrote: > >> The discussion started by Stephan suggesting that free software >> authors publish their work as free standards in the IETF. My point >> was that since the IETF disallow publishing standards under a license >> that is compatible with free software licensing (e.g., allows >> modification), it is not possible for free software authors to do >> this. Thus, to me, this discussion is not related to comments in >> source code at all. > > My understanding of IETF policy is that the IETF will publish I-Ds that > are in the public domain. Nothing is freer than that. You're > perfectly free to put your text in the public domain before submitting > it for publication as an RFC. Or afterwards, since the license a contributor grants to the IETF Trust is non-exclusive. So contributing these words to the IETF does not affect in any way my ability to do as I wish with them after hitting the Send button. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Fwd: Re: Changes needed to Last Call boilerplate]
On 2009-02-13 21:15, Henk Uijterwaal wrote: > > Noel Chiappa wrote: > > (Discussion deleted) > >> I think these (and the per-draft mailboxes others have mentioned) are >> probably >> all steps in a long-term plan, with the eventual optimum system being the >> web-based thing you mention. > > What is exactly the problem we're trying to solve here? Henk, at least in my mind it is *not* solving the outlier case of an organised mail bombing; pretty much any solution that remains in the IETF spirit of openness will be subject to some kind of bombing (and probably should be, if we're serious about being an open [dis]organisation). In my mind the problem is how to collect and classify all the comments on a given draft, so that the authors, the WG, the IESG, and anyone else who needs to, can review them all. Being able to do that easily would be a significant benefit for the efficiency of document review. and would help make our process more transparent. > I think most of us like to see LC comments related to the drafts that > they are somehow involved with (author, WG participant, etc). Posting > those comments to the ietf list takes care of that, without work or > effort from anybody. Not so, if people disrespect the request to retain the subject header of the Last Call message. I assure you from my time on the IESG, when I was supposed to have an opinion about the consensus from every Last Call, that the lack of fully automatic sorting of comments was a major pain. It's even worse when the IESG or IAB needs to review a document's history because of an appeal. > Most of the 250+ drafts that go last call every year, generate no > comments on the list. And that's a problem in itself. > The TLS draft is an exception with 100's of > replies. However, I cannot remember any similar cases in the last > 10 years. Pressing delete 100 times worked for me, that is a few > minutes of work in a 10 year period, in other words no work at all. I agree completely; it's not the main problem. > > Do we really want to introduce all kinds of complex procedures just > based on one incident? No... as explained above. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: References to Redphone's "patent"
Lawrence: I think we are close to intellectual agreement([0]), but see below. (Nothing to do about my personal position as an [---] advice provider.) Lawrence Rosen wrote: Thierry Moreau wrote: Check by yourself, I do not provide professional advice in here. And that's why I made my suggestion that we do these analyses in a professional manner! Too many patent-savvy attorneys (and their companies?) expect the community to decide these things in a random fashion. The IETF--collectively--needs professional advice, including from you. I will allow that you speak for yourself and offer no guarantees or warranties. But expert attorneys need to give us their expert opinions about the effects of specific patents on our specific work. That's why I'm so irritated that the previous IPR WG, since disbanded (fortunately), refused even to discuss a patent policy for IETF. Of course such studied ignorance can lead to community displays of confusion and anger. Hence the FSF campaign and others like it; entirely justified. Maybe s/justified/to be expected/? I don't quite follow how the FSF campaign may be justified if the underlying patent application details has been ignored. If among the high volume e-mails triggerd by the FSF there was one based on "finer investigation and analysis", I would expect the IESG to count this one as an IETF community participation. Simon, as a GnuTLS project leader, stated he did not read the patent. You seem to suggest that "studied ignorance" should be fixed at the IETF/IESG institution level, and until done, the institution gets what it deserves (i.e. is hurt by FSF and othe campaigns as expected). I'm comfortable with either way, fighting studied ignorance at the participant or institution level. - Thierry Moreau [0] "intellectual agreement" is distinct from "agreement" as understood by a lawyer and "agreement" in the terminology used in UP patent application 11/234,404 - by the way it's Friday afternoon! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: References to Redphone's "patent"
At 10:48 AM -0800 2/13/09, Lawrence Rosen wrote: >That's why I'm so irritated that the previous IPR WG, since disbanded >(fortunately), refused even to discuss a patent policy for IETF. Armed with my calming cup of white tea, I point out that this is not true. The group considered the question of whether an update in this area was required, and it declined to take on any change. The current policy is that IETF participants are required to notify the IETF of any IPR which they reasonably and personally know to cover a contribution. This allows individual participants to make informed decisions about whether they wish to support work on those contributions and the WGs and IETF as a whole whether it wishes to publish the work, given the known situation. Taking that set of decisions out of the WGs and into a specialist body has substantial risks, chief among them the risk that the body's analysis of the risk does not come with insurance cover for the decisions taken by individuals. If the body says "This patent application is invalidated by prior art" and the patent examiners do not agree, those who have acted on that basis are in a troublesome situation. If the specialist body says "This patent does not cover this draft" and a court later disagrees, the same is true. Also, if the body says "this patent does cover this draft", it is the WG participants who spend time and effort to develop an alternative, possibly only to later discover that they would have disagreed with the specialist body on either the coverage or the risks inherent in infringement. The IPR working group also pointed out, repeatedly, the risk in demanding that all submissions to the IETF have no known encumbrance: anyone can claim they have covering IPR at any time and use that tool to block progress on a standard. Given the value of maintaining a proprietary lock on some areas, this is a substantial risk. The IETF policy amounts to this: you must disclose what you know, and the people impacted by the decision make it. I'm sorry that irritates you, Larry, but I remain convinced that it is the right thing for the IETF. Two cents and one bag of "Moonlight Spice", steeped 5 minutes, worth of opinion, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: References to Redphone's "patent"
> From: "Lawrence Rosen" > the previous IPR WG .. refused even to discuss a patent policy for IETF. I thought the IETF sort of had one, though (see RFC mumble)? I definitely agree that the IETF could use some sort of permanent legal IPR consulting board that WG's could go to and say 'we have this IPR filing, what does it mean, and what is the likely impact on our work'. And of course that board would have to have people with professional expertise in IPR on it (i.e. patent attorneys) - although IMO I think it would be more effective if it were not _just_ attorneys, but also included some engineers with experience with the IPR world (e.g. as expert witnesses), to help interface between the two cultures! :-) Just briefly, what are the problems you see with the existing IETF patent policy (other than not having such an consulting board)? Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call for Comments: Proposed work-around to the Pre-5378 Problem
When will http://xml.resource.org/ and xml2rfc be updated to include this? Are there any changes we need to make to our input xml files? - Wes From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ed Juskevicius Sent: Thursday, February 12, 2009 7:53 PM To: ietf@ietf.org; ietf-annou...@ietf.org; wgcha...@ietf.org; i...@iab.org; i...@ietf.org; rfc-edi...@rfc-editor.org Cc: Trustees; Contreras,Jorge Subject: Re: Last Call for Comments: Proposed work-around to the Pre-5378 Problem I am pleased to announce that the IETF Trustees have just finished work on a revision to our "Legal Provisions Relating to IETF Documents" policy. The revision includes optional new legend text in Section 6.c.iii of the policy to serve as a work-around for people experiencing the "pre-5378 problem." Please note the newly approved policy is dated 2009-02-12. Please also note that the Effective Date of this revised policy has been set to 2009-02-15. The old policy (effective from November 10, 2008) remains in force until 00h00 UTC on February 15th. The approved text is available now on IETF Trust website at http://trustee.ietf.org/policyandprocedures.html Please look for the document dated 2009-02-12, just below the heading labeled "DRAFT Policy and Procedures Being Developed." On or shortly after February 15th, the Trust website will be updated so as to archive all of the recent draft versions of the new policy, and to make it easier to navigagte to the newly approved policy. Please review the new policy so you are aware of the latest copyright statements and other boilerplate legend text that will be required on all contributions to the IETF starting on February 15, 2009. Regards, and Thanks in advance, Ed Juskevicius, on behalf of the IETF Trustees edj@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: References to Redphone's "patent"
Thierry Moreau wrote: > Check by yourself, I do not provide > professional advice in here. And that's why I made my suggestion that we do these analyses in a professional manner! Too many patent-savvy attorneys (and their companies?) expect the community to decide these things in a random fashion. The IETF--collectively--needs professional advice, including from you. I will allow that you speak for yourself and offer no guarantees or warranties. But expert attorneys need to give us their expert opinions about the effects of specific patents on our specific work. That's why I'm so irritated that the previous IPR WG, since disbanded (fortunately), refused even to discuss a patent policy for IETF. Of course such studied ignorance can lead to community displays of confusion and anger. Hence the FSF campaign and others like it; entirely justified. /Larry Lawrence Rosen Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243 Skype: LawrenceRosen > -Original Message- > From: Thierry Moreau [mailto:thierry.mor...@connotech.com] > Sent: Friday, February 13, 2009 10:20 AM > To: lro...@rosenlaw.com > Cc: ietf@ietf.org > Subject: Re: References to Redphone's "patent" > > > > Lawrence Rosen wrote: > > > Lots of the recent emails on this list refer to Redphone's "patent" but > > there is no such thing. > > > > In my emails, I used the reference to US patent application 11/234,404 > as amended on 2008/01/25. > > > As anyone who has ever worked with real patents knows, there is a great > > difference between a patent application and a patent. Whatever claims > are > > written in patent applications are merely wishes and hopes, placeholders > for > > negotiated language after a detailed examination of the application. > Until > > the PTO actually issues a patent, nothing is fixed. And even then, > > newly-found prior art and other issues can defeat an issued patent. > > > > Indeed, plus the geographical applicability restrictions that are > determined 30 or 31 months after the priority date according to PCT > rules - the above patent application has national or regional > applications in Australia, Canadian, and the EU (I didn't check the EPO > database, perhaps it's not the whole EPC member states). > > > Why are we all so afraid of Redphone? Who gives a damn what patent > claims > > they hope to get? > > > > I guess (i.e. speculate) that it is more convenient for the FSF to get > publicity / support with a case involving a small organization without > significant market presence and lobbying resources that could retaliate > an FSF campaign more visibly. I thought the GnuTLS connection triggered > the FSF action, but Simon corrected me on this hypothesis. > > > There's something wrong with the IETF process if spurious and self- > serving > > assertions that "a patent application has been filed" can serve to hold > up > > progress on important technology. I wish you'd ask real patent attorneys > to > > advise the community on this rather than react with speculation and a > > generalized fear of patents. > > > > I agree. > > You may notice that the FSF did not share (AFAIK) any result of > investigation into the patent application status which would include > some professional advice. > > Actually, two PCT/WIPO search/examination reports are on-line, and one > *denies* novelty to every claims but 3 of them, and denies inventive > step to all of them! The patent applicant may (further) amend the claims > at the national or regional phase, but the initial assessment is not so > good for the patent applicant. Check by yourself, I do not provide > professional advice in here. > > So it's really the FSF campaign that is detracting the IETF process here > in the way you are alluding above. The Redphone's IPR disclosure 1026 > verbatim does not detract the IETF process. > > Again, finer investigations and analyses of IPR issues (finer than > ideological opposition to patents) would be benefitial to the IETF. > > Regards, > > > - Thierry Moreau ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Changes needed to Last Call boilerplate
On Fri, Feb 13, 2009 at 10:22:39AM +, Michael Dillon wrote: > If you really want to limit it to people subscribed to the list, forget the > boilerplate, just configure Mailman differently. Enthusiastic second, as this is a better and cleaner idea, preferable over the overly-complex alternatives proposed. (The same could be done to other lists as well.) It isn't at all difficult to facilitate this kind of discussion just by using the features that are already there. (And if there's a need for a feature which doesn't yet exist? The Mailman community has shown itself quite responsive to the needs and suggestions of users, doubly so when those are accompanied by working code.) I find web-based forums idiosyncratic, difficult-to-use, and resistant to offline reading, archiving and searching. Mail is still, by a huge margin, the very best means of conducting these conversations. ---Rsk ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-tls-authz-extns-07.txt
Hello. The FSF and I just followed your instructions to send comments to that email address as said at the end of http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05617.html . Accepting that proposal as a standard is dangerous without RedPhone being more clear about their IPR, making sure that they will not only sue implementers of that method, but also that they won't sue users of the method! Having Internet standards that are openly implementable and usable without restrictions is very very important, otherwise you will be creating a divide between some people being able to use some standards and some people left behind. Please, understand this and do the right thing, you know what the right thing is, every human knows! Thanks. El 11/02/09 20:58, Noel Chiappa escribió: Thank you for being part of a crowd of hundreds of people who have mailbombed the mailboxes of thousands of IETF 'members' (since we don't have any formal membership, just an email list). As a result, we all have such positive feeling about the FSF. Noel -- Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/ From Montevideo, Uruguay, at the south of South America. Freelance programmer and GNU/Linux system administrator, hire me! Alternatives: iba...@codigolibre.net - http://go.to/ibaldo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call for Comments: Proposed work-around to the Pre-5378 Problem
I am pleased to announce that the IETF Trustees have just finished work on a revision to our "Legal Provisions Relating to IETF Documents" policy. The revision includes optional new legend text in Section 6.c.iii of the policy to serve as a work-around for people experiencing the "pre-5378 problem." Please note the newly approved policy is dated 2009-02-12. Please also note that the Effective Date of this revised policy has been set to 2009-02-15. The old policy (effective from November 10, 2008) remains in force until 00h00 UTC on February 15th. The approved text is available now on IETF Trust website at http://trustee.ietf.org/policyandprocedures.html Please look for the document dated 2009-02-12, just below the heading labeled "DRAFT Policy and Procedures Being Developed." On or shortly after February 15th, the Trust website will be updated so as to archive all of the recent draft versions of the new policy, and to make it easier to navigagte to the newly approved policy. Please review the new policy so you are aware of the latest copyright statements and other boilerplate legend text that will be required on all contributions to the IETF starting on February 15, 2009. Regards, and Thanks in advance, Ed Juskevicius, on behalf of the IETF Trustees edj@gmail.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07
I too would like to figure out what the questions are. The draft is not about carrying "authorizations" in TLS, or that "The main issue with these authorization extensions inside TLS is that they happen at the wrong layer" as stated by Hannes Tschofenig. Authorization happens at the application layer. Data is transported at the transport layer. The draft is about carrying data (SAML assertions, attribute certificates, or pointers thereto) that can be used or ignored by applications when those applications make authorization decisions. What application domain is involved when I hand someone a certificate (driver's license) stating that I was born on MMDD? It only becomes part of an application domain when the "someone" is instantiated as a store clerk who needs to decide whether I am authorized to buy cigarettes or liquor. The clerk is doing the authorization, not the certificate. Since Mr. Anderson is so exercised about the word "authorization" in the name of the I-D, perhaps it should be renamed "draft-ietf-tls-attributes-07". That would avoid the IPR issues entirely, since one can transport an attribute certificate without ever using it to authorize anything. -Original Message- From: Josh Howlett [...] > My experience: authorization is often related to the specific > application domain. I agree insofar as 'authorisation' is often an exercise in making statements using semantics that are specific to application domains, but I don't believe it follows that the syntactical and transport elements (that support the semantic expression) also need to be specific to the application domain. [...] > Looking forward to see your solutions. I have no answers; I'm still trying to figure out what the questions are :-/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07
Sam, Is your suggestion that there is a better existing working group, or to establish one through the BOF process? We are interested both in leveraging at the application layer an authentication context established by TLS between A and B (as opposed to relying on an SSO assertion from C to B that C has authenticated A), and in carrying A's authorization-related attributes (pre-signed by C) within that context. I was aware of this discussion only because it came to TLS, and would welcome a pointer to the right forum. -Original Message- From: Sam Hartman Sent: Thursday, February 12, 2009 5:40 PM To: Josh Howlett Cc: Hannes Tschofenig; t...@ietf.org; ietf@ietf.org Subject: Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07 [...] For these reasons I support the publication of a standard in this space. I don't object to this work going to the TLS working group provided that 1) it is within their current charter 2) They commit to do the work and have sufficient energy to move it forward quickly. I do object to moving the discussion of whether to solve this problem to the TLS working group. I don't think that is the right forum: the TLS working group does not collect the people who would benefit from this work. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Changes needed to Last Call boilerplate
I think my proposal for an easy way to automatically subscribe to all last call lists avoids that concern for folks such as yourself who want to follow the discussion while providing the operational efficiency of collecting all discussion in one place for actual analysis of last call concensus. Amoung other things, I would expect that when a specific last call was out of my range of concern, I could unsubscribe from that specific discussion. I've mentioned last call concensus analysis, but having individual archives would help anyone who suddenly discovered a concern to easily retrieve all related comments. Dave Morris On Fri, 13 Feb 2009, Wes Beebee (wbeebee) wrote: Note also that e-mails sent to ietf+draft-n...@ietf.org would not be sent to the general list of i...@ietf.org. I think this is potentially dangerous. I use the ietf@ietf.org list to find out about work that's going on that I wouldn't know to tune into. Sometimes the issues presented are not just relevant to the draft being discussed, but have some broader community impact. It is indeed this broader community impact that is often decided in an IETF Last Call, otherwise we would only have Working Group Last Calls and no IETF Last Call... - Wes -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Willie Gillespie Sent: Thursday, February 12, 2009 9:34 PM To: David Morris Cc: ietf@ietf.org Subject: Re: Changes needed to Last Call boilerplate David Morris wrote: Seems like a unique mailbox per lastcall would be very helpful all around. Right now, gathering and evaluating comments must be a nightmare. An alternative, would be a single LC mailbox as suggested, but require EVERY subject line to carry the last call ID, preferable in a form sensible to current mail clients. In the case of unique lists per lastcall, provide an opt-in metasubcribe to make it easy for folks who generally want to follow last call discussions to just be subscribed. *AND* require subscribe to post ... no cute confirm reply to bypass. I strongly believe that anyone who wants to provide feedback should want to see the comments on their feed back. [If the cute confirm created an automatic 48 hour subscription as per my next point, that would work too.] *AND* no unsubscribe or post only for 48 hours after initial subscription. For real participants, this wouldn't be an issue and for email campaigns, well they just need to experience the same disrruption their campaign causes. David Morris Not a bad idea. In fact, it may be useful to have a unique "list" per draft, so every comment relating to a particular draft can be tracked historically. This example is how I understand your suggestion: ietf+housley-tls-authz-ex...@ietf.org will automatically be set up with the initial ID submission. E-mails sent to it will be regarded as discussion pertaining to the draft. Individuals interested in following the draft may subscribe to that list simply by sending an e-mail to it. (However, e-mails with simply the word "subscribe" in the body or subject line won't be forwarded to everyone.) They are also allowed to unsubscribe (perhaps following the 48-hour waiting period of initial subscription as David suggested). Note also that e-mails sent to ietf+draft-n...@ietf.org would not be sent to the general list of i...@ietf.org. I doubt this sort of functionality currently exists in Mailman, but perhaps it could be implemented. Willie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: References to Redphone's "patent"
Lawrence Rosen wrote: Lots of the recent emails on this list refer to Redphone's "patent" but there is no such thing. In my emails, I used the reference to US patent application 11/234,404 as amended on 2008/01/25. As anyone who has ever worked with real patents knows, there is a great difference between a patent application and a patent. Whatever claims are written in patent applications are merely wishes and hopes, placeholders for negotiated language after a detailed examination of the application. Until the PTO actually issues a patent, nothing is fixed. And even then, newly-found prior art and other issues can defeat an issued patent. Indeed, plus the geographical applicability restrictions that are determined 30 or 31 months after the priority date according to PCT rules - the above patent application has national or regional applications in Australia, Canadian, and the EU (I didn't check the EPO database, perhaps it's not the whole EPC member states). Why are we all so afraid of Redphone? Who gives a damn what patent claims they hope to get? I guess (i.e. speculate) that it is more convenient for the FSF to get publicity / support with a case involving a small organization without significant market presence and lobbying resources that could retaliate an FSF campaign more visibly. I thought the GnuTLS connection triggered the FSF action, but Simon corrected me on this hypothesis. There's something wrong with the IETF process if spurious and self-serving assertions that "a patent application has been filed" can serve to hold up progress on important technology. I wish you'd ask real patent attorneys to advise the community on this rather than react with speculation and a generalized fear of patents. I agree. You may notice that the FSF did not share (AFAIK) any result of investigation into the patent application status which would include some professional advice. Actually, two PCT/WIPO search/examination reports are on-line, and one *denies* novelty to every claims but 3 of them, and denies inventive step to all of them! The patent applicant may (further) amend the claims at the national or regional phase, but the initial assessment is not so good for the patent applicant. Check by yourself, I do not provide professional advice in here. So it's really the FSF campaign that is detracting the IETF process here in the way you are alluding above. The Redphone's IPR disclosure 1026 verbatim does not detract the IETF process. Again, finer investigations and analyses of IPR issues (finer than ideological opposition to patents) would be benefitial to the IETF. Regards, - Thierry Moreau ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Changes needed to Last Call boilerplate
> Note also that e-mails sent to ietf+draft-n...@ietf.org would not be sent to the general list of i...@ietf.org. I think this is potentially dangerous. I use the ietf@ietf.org list to find out about work that's going on that I wouldn't know to tune into. Sometimes the issues presented are not just relevant to the draft being discussed, but have some broader community impact. It is indeed this broader community impact that is often decided in an IETF Last Call, otherwise we would only have Working Group Last Calls and no IETF Last Call... - Wes -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Willie Gillespie Sent: Thursday, February 12, 2009 9:34 PM To: David Morris Cc: ietf@ietf.org Subject: Re: Changes needed to Last Call boilerplate David Morris wrote: > Seems like a unique mailbox per lastcall would be very helpful all around. > Right now, gathering and evaluating comments must be a nightmare. An > alternative, would be a single LC mailbox as suggested, but require > EVERY subject line to carry the last call ID, preferable in a form > sensible to current mail clients. > > In the case of unique lists per lastcall, provide an opt-in > metasubcribe to make it easy for folks who generally want to follow > last call discussions to just be subscribed. > > *AND* require subscribe to post ... no cute confirm reply to bypass. I > strongly believe that anyone who wants to provide feedback should want > to see the comments on their feed back. [If the cute confirm created > an automatic 48 hour subscription as per my next point, that would > work too.] > > *AND* no unsubscribe or post only for 48 hours after initial subscription. > For real participants, this wouldn't be an issue and for email > campaigns, well they just need to experience the same disrruption > their campaign causes. > > David Morris Not a bad idea. In fact, it may be useful to have a unique "list" per draft, so every comment relating to a particular draft can be tracked historically. This example is how I understand your suggestion: ietf+housley-tls-authz-ex...@ietf.org will automatically be set up with the initial ID submission. E-mails sent to it will be regarded as discussion pertaining to the draft. Individuals interested in following the draft may subscribe to that list simply by sending an e-mail to it. (However, e-mails with simply the word "subscribe" in the body or subject line won't be forwarded to everyone.) They are also allowed to unsubscribe (perhaps following the 48-hour waiting period of initial subscription as David suggested). Note also that e-mails sent to ietf+draft-n...@ietf.org would not be sent to the general list of i...@ietf.org. I doubt this sort of functionality currently exists in Mailman, but perhaps it could be implemented. Willie ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Changes needed to Last Call boilerplate
Michael Dillon wrote: > With the text above, don't be surprised when people learn that they can > become bona fide IETF members by subscribing to the IETF discussion list and > the new subscription volume swells exponentially. Given the contents of many > of the letters received on the patent issue, I would expect the majority of > those people to be willing, and capable of, subscribing to the IETF list in > order to submit a comment. > > Also, don't be surprised when the next time this issue arises, the FSF > encourages people to join the IETF WG discussing the next patent-encumbered > draft. Those would be positive steps. I don't think we object to hearing what people have to say about any topic simply because they happen to be FSF members. What we object to is a bunch of "me too" comments that present no new points, and are clearly coming from people who a) aren't also receiving them, and b) aren't participating in discussion. I do like that the IETF list allows non-subscribers to post, even though it makes these annoyances possible. However, if we do something that causes the FSF to encourage people to subscribe if they wish to comment, rather than encouraging people to do the sort of drive-by we've seen, we'd be happier and they'd be happier. Those people who don't feel like putting much time into it wouldn't subscribe; those people who do feel like putting some of their time into it would be more engaged; the number of substantively identical messages would be much more self-limiting if a significant proportion of the would-be activists were subscribed. -- Cos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Fwd: Re: Changes needed to Last Call boilerplate]
> From: "HUANG, ZHIHUI (JERRY), ATTLABS" > asking only "the IETF community" to respond to LC and even explicitly > state that "one should only respond (to LC) if he's subscribed to foo > and bar IETF mailing list" will probably not deter people from > 'drive-by' subscribing and posting of knee-jerk comments. Hence my suggestion of a separate mailing list. If the only list mentioned in the LC is "ietf-comments", I think people are not likely to find "ietf" on their own. Oh, and that suggestion that we change the wording to be "The IESG solicits final comments from the IETF community on whether the IETF community has consensus to publish" - that would be a good idea to do if we _don't_ set up a separate mailbox. If we _did_, we should leave it out, so that the public _does_ have someplace to send comments. Still, IMO 'one mailbox, no public comments' and 'one mailbox, accept public comments' are both inferior (for different reasons) to 'two mailboxes, accept public comments'. > But that's what will amount to if .. (3) no regulars would take the > risk to subscribe to the new mailing list. So no comment on the new > mailing list would effectively be heard. I was not recommended that the new mailbox be a bit-bucket - I explicitly called for it to be monitored by someone(s) who would bring anything novel and/or significant to all our attention. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Fwd: Re: Changes needed to Last Call boilerplate]
From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu]
>> From: "HUANG, ZHIHUI (JERRY), ATTLABS"
>> We shouldn't assume that FSF will not learn from feedbacks
>
>...
>- it continued to call for sending email to i...@ietf.org.
Point taken. But still, FSF and RMS may hold philosophically rigid
positions, they surely can't turn a deaf ear to proposals to help them
get their reasoned position heard, which is to say "this and like future
email campaigns do nothing to IETF community's receptiveness to FSF's
advocated position, a well thought-out note from the FSF would suffice."
>> Isn't that the right price to pay for an open forum?
>
>You will note that I explicitly did not, in my suggested change to the
LC, say
>"close the IETF list to non-subscriber posts". However, that's a long
way from
>hanging out a "Kick Me" sign, which is what the current LC text ('send
>comments to ietf@ietf.org') effectively amounts to, for those who don't
>carefully read it, and notice that it's directed to 'the IETF
community'.
As someone else pointed out earlier, asking only "the IETF community" to
respond to LC and even explicitly state that "one should only respond
(to LC) if he's subscribed to foo and bar IETF mailing list" will
probably not deter people from 'drive-by' subscribing and posting of
knee-jerk comments. So it doesn't really solve the problem. Even IETF
participants can and do get their posting 'right' suspended for various
reasons so the problem is not strictly from 'outside people'.
>> If you know the secret handshake
>
>That's rather unfair.
But that's what will amount to if (1) IETF announces that comments to LC
be posted to a new mailing list; and (2) only the regulars know that
"the real place to be heard is at ietf@ietf.org"; and (3) no regulars
would take the risk to subscribe to the new mailing list. So no comment
on the new mailing list would effectively be heard.
>[The] IETF is hardly a secret society which is picky about new blood
This is certainly not what my post was supposed to imply.
>
> Noel
Jerry Huang
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: FSF's comment on draft-housley-tls-authz-extns
+1 Regards, Chuck - Chuck Powers, Motorola, Inc phone: 512-427-7261 mobile: 512-576-0008 > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On > Behalf Of ned+i...@mauve.mrochek.com > Sent: Friday, February 13, 2009 10:14 AM > To: Sam Hartman > Cc: ietf@ietf.org > Subject: Re: FSF's comment on draft-housley-tls-authz-extns > > > ... > > > I'm sorry, I don't see this at all. I appreciate that you > quoted the > > text in question. However I don't see anything in the language you > > quote that applies differently to either users or developers. > > Well, there's something of an exemption for developers > producing generic > uilding block software. But I take your point to be that a > developer who, say, > puts in specialized support for a Redphone critical extension > (item one of the > four), would clearly be infringing. > > > The text is saying that the transport mechanisms described in the > > Housley draft are not covered by the patent. However the > text goes on > > to say that some ways in which an implementation might employ those > > transport mechanisms would be covered by the patent. As I read the > > text, both developers and users who used the mechanisms in > the Housley > > draft in any of these four ways would infringe the patent, Redphone > > claims. > > Nicely put. I agree with this assessment. > > > However I'll also note that there are significant uses of the > > transport mechanisms in the Housley draft that are > interesting both to > > the free software and IETF communities that fall well outside these > > four areas. In particular, transporting in-band group > memberships and > > authorization/attribute assertions see.ms to fall outside > these areas. > > Exactly. > > > I can understand why the GNU project would not choose to ship an > > extension to GNU TLS that used this transport to send agreement > > locations. > > Sure, that would clearly infringe. The question to my mind is > whether or not > this is an overly onerous restriction. I don't think it is > but others may > disagree. > > > However, it is completely absurd to claim that because some > > infrastructure building block could (by writing additional software) > > be used in a manner that infringes a patent that no free software > > version of that building block can exist. As an example, the FSF > > ships a compiler collection that can be used to infringe a number of > > patents in the hands of someone who has infringing source code. The > > GNU/Linux kernel includes a TCP implementation that can be used to > > infringe Redphone's patent. > > This is the point I was trying to make in my earlier > response. There are many > use-case patents built on top of pretty much any protocol > building block you > can think of. If we adopt the theory, which is implicit in many of the > objections I've seem to this document, that we cannot work on > protocol building > blocks when such use-case patents exist, we'll effectively be > out of business. > > I will also point out that the list of IPR disclosures > includes very few of > these patents. Demanding the disclosure of all such patents > participants are > aware of would be ... interesting. > > Ned > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: FSF's comment on draft-housley-tls-authz-extns
> ... > I'm sorry, I don't see this at all. I appreciate that you quoted the > text in question. However I don't see anything in the language you > quote that applies differently to either users or developers. Well, there's something of an exemption for developers producing generic uilding block software. But I take your point to be that a developer who, say, puts in specialized support for a Redphone critical extension (item one of the four), would clearly be infringing. > The text is saying that the transport mechanisms described in the > Housley draft are not covered by the patent. However the text goes on > to say that some ways in which an implementation might employ those > transport mechanisms would be covered by the patent. As I read the > text, both developers and users who used the mechanisms in the Housley > draft in any of these four ways would infringe the patent, Redphone > claims. Nicely put. I agree with this assessment. > However I'll also note that there are significant uses of the > transport mechanisms in the Housley draft that are interesting both to > the free software and IETF communities that fall well outside these > four areas. In particular, transporting in-band group memberships and > authorization/attribute assertions see.ms to fall outside these areas. Exactly. > I can understand why the GNU project would not choose to ship an > extension to GNU TLS that used this transport to send agreement > locations. Sure, that would clearly infringe. The question to my mind is whether or not this is an overly onerous restriction. I don't think it is but others may disagree. > However, it is completely absurd to claim that because some > infrastructure building block could (by writing additional software) > be used in a manner that infringes a patent that no free software > version of that building block can exist. As an example, the FSF > ships a compiler collection that can be used to infringe a number of > patents in the hands of someone who has infringing source code. The > GNU/Linux kernel includes a TCP implementation that can be used to > infringe Redphone's patent. This is the point I was trying to make in my earlier response. There are many use-case patents built on top of pretty much any protocol building block you can think of. If we adopt the theory, which is implicit in many of the objections I've seem to this document, that we cannot work on protocol building blocks when such use-case patents exist, we'll effectively be out of business. I will also point out that the list of IPR disclosures includes very few of these patents. Demanding the disclosure of all such patents participants are aware of would be ... interesting. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
References to Redphone's "patent"
Lots of the recent emails on this list refer to Redphone's "patent" but there is no such thing. As anyone who has ever worked with real patents knows, there is a great difference between a patent application and a patent. Whatever claims are written in patent applications are merely wishes and hopes, placeholders for negotiated language after a detailed examination of the application. Until the PTO actually issues a patent, nothing is fixed. And even then, newly-found prior art and other issues can defeat an issued patent. Why are we all so afraid of Redphone? Who gives a damn what patent claims they hope to get? There's something wrong with the IETF process if spurious and self-serving assertions that "a patent application has been filed" can serve to hold up progress on important technology. I wish you'd ask real patent attorneys to advise the community on this rather than react with speculation and a generalized fear of patents. /Larry Lawrence Rosen Rosenlaw & Einschlag, a technology law firm (www.rosenlaw.com) 3001 King Ranch Road, Ukiah, CA 95482 707-485-1242 * cell: 707-478-8932 * fax: 707-485-1243 Skype: LawrenceRosen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Fwd: Re: Changes needed to Last Call boilerplate]
> From: "HUANG, ZHIHUI (JERRY), ATTLABS"
> We shouldn't assume that FSF will not learn from feedbacks
Well, I don't know. RMS's intial response to my lengthy note (which I CC'd
this list, I tried to make it productive in tone) to the FSF board (although
the FSF is still basically RMS, as far as I can make out) was not indicative
of a change in course; and their appeals page was updated a day later, but
left basically unchanged - it continued to call for sending email to
i...@ietf.org.
>> And no doubt, if it continues to be allowed, it will happen again.
Perhaps "seemingly encouraged" (I meant, by the wording of the LC) would have
been a better phrase than "allowed".
> Isn't that the right price to pay for an open forum?
You will note that I explicitly did not, in my suggested change to the LC, say
"close the IETF list to non-subscriber posts". However, that's a long way from
hanging out a "Kick Me" sign, which is what the current LC text ('send
comments to ietf@ietf.org') effectively amounts to, for those who don't
carefully read it, and notice that it's directed to 'the IETF community'.
> If you know the secret handshake
That's rather unfair.
The IETF web site is easily findable, and we impose no barrier of any kind
(cost, qualifications, etc) to anyone joining any of our email lists. The
IETF is hardly a secret society which is picky about new blood - almost
_everyone_ on this list these days is 'new' since the 'old days' (circa 1970s
for a few of us).
Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: [Fwd: Re: Changes needed to Last Call boilerplate]
Noel Chiappa said on Friday, February 13, 2009 8:59 AM >> From: Henk Uijterwaal > >> What is exactly the problem we're trying to solve here? > >Having people's mailboxes explode from ill-considered public pressure >campaigns? At the start, I got as much email in one hour as I often get in a >week. That's really not the problem, is it? The problem is that we are forced to deal with "ill-considered public pressure campaigns". I forgot who made it but the previous proposal of subtle changes in the LC language would go a long way of dissuading future campaigns, IMHO. On the other hand, why not have someone in an official capacity (IETF Chair or some such) work with FSF on the best way to contribute to IETF work, instead of instigating email campaigns that only serves to irk the IETF community in general? Their position (as stated in John Sullivan's email) is not that unreasonable. We shouldn't assume that FSF will not learn from feedbacks - aside from condescending comments. >> Do we really want to introduce all kinds of complex procedures just >> based on one incident? > >Well, it's not the first time - the FSF pulled the same stunt back in October >of 2007. And no doubt, if it continues to be allowed, it will happen again. Isn't that the right price to pay for an open forum? Or are we going to have a committee pre-screen submitted for technical merits before being posted to mailing lists? >My original proposal was very simple: create one more list as a formal notice >place for LC's, since many of the FSF drive-by posters were saying 'but, but >your LC said send comments here'. > >Anyway, nothing is stopping an IETF person from sending email to the IETF list >about something they want to bring up there, so if an LC has something that >really bugs someone in the IETF, they can still send email to the IETF list >about it. > Of course, this works. If you know the secret handshake, your opinion will be heard; else your comments are delivered to a bit bucket where no one with apparently sound technical mind will ever see - since _they_ know better than to subscribe to "LC comment's mailing list". > Noel -- Jerry Huang, AT&T Labs, +1 630 810 7679 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Fwd: Re: Changes needed to Last Call boilerplate]
Despite currently excessive number of comments, I think we should invite more comments and make it easier, not harder to send them. Even if traffic on the list is now too high and information content per message is low, in general our average number of comments in the IETF Last Call stage is too low. I don't have a problem with the number of messages. Deleting is easy. But I wouldn't mind stricter enforcement of the Subject lines... Note that this opinion is entirely separate from the value of the comments. Repetition and mail bombing is not valuable. Well justified opinions are very valuable. The latter may come from both inside and outside the IETF; sometimes experts on some topic can be persuaded to send in a comment, but not to subscribe to lists or engage in lengthy debate. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: FSF's comment on draft-housley-tls-authz-extns
> "John" == John Sullivan writes:
John> The Licensing Declaration starts out right:
>> RedPhone Security hereby asserts that the techniques for
>> sending and receiving authorizations defined in TLS
>> Authorizations Extensions (version
>> draft-housley-tls-authz-extns-07.txt) do not infringe upon
>> RedPhone Security's intellectual property rights (IPR).
John> However, it is then followed by an important caveat:
>> The values provided in, and the processing required by the
>> authorizations ("authz_data" in the Protocol Document) sent or
>> received using the techniques defined in TLS Authorizations
>> Extensions are not specified in the Protocol Document. When an
>> implementation generates the authorizations or processes these
>> authorizations in any of the four ways described below, then
>> this practice may be covered by RedPhone Security's patent
>> claims.
John> It appears that RedPhone's disclaimer covers software
John> developers who implement the standard in a vague sense, but
John> not the people who then actually use that software. A patent
John> disclaimer must clearly cover both developers and users to
John> be acceptable.
I'm sorry, I don't see this at all. I appreciate that you quoted the
text in question. However I don't see anything in the language you
quote that applies differently to either users or developers.
The text is saying that the transport mechanisms described in the
Housley draft are not covered by the patent. However the text goes on
to say that some ways in which an implementation might employ those
transport mechanisms would be covered by the patent. As I read the
text, both developers and users who used the mechanisms in the Housley
draft in any of these four ways would infringe the patent, Redphone
claims.
However I'll also note that there are significant uses of the
transport mechanisms in the Housley draft that are interesting both to
the free software and IETF communities that fall well outside these
four areas. In particular, transporting in-band group memberships and
authorization/attribute assertions see.ms to fall outside these areas.
I can understand why the GNU project would not choose to ship an
extension to GNU TLS that used this transport to send agreement
locations.
However, it is completely absurd to claim that because some
infrastructure building block could (by writing additional software)
be used in a manner that infringes a patent that no free software
version of that building block can exist. As an example, the FSF
ships a compiler collection that can be used to infringe a number of
patents in the hands of someone who has infringing source code. The
GNU/Linux kernel includes a TCP implementation that can be used to
infringe Redphone's patent.
I'd agree with you that things would be problematic for the free
software community if the ways in which this technology were going to
be used by free software infringed the patent. I also agree with you
that there are things that one could choose to standardize on top of
this draft that would be highly problematic for the free software
community. Should anyone choose to standardize those items, I will
join you in a protest.
Until then, please pick battles worth fighting. There are a lot of bad patent
issues out there; this is no where near the top.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Please reject the patent-encumbered proposed standard for TLS authorization
Dear Sir; On Feb 11, 2009, at 6:06 PM, MBR wrote: Dear Noel, It's unfortunate, but I know of no way to tell the difference between an email address that's the main point of contact for an organization and an email address that distributes to a huge mailing list. I sent email to ietf@ietf.org, naively assuming that the Internet Engineering Task Force was established enough to have an office somewhere with a secretary who read the emails and forwarded those of interest to the appropriate people. Part of the rough democracy of the IETF is that there are basically no filters to reaching any person in a position of responsibility. The IETF Chair, the IAB Chair, the IESG, the general discussion list, Working Group Chairs, all can be easily contacted by anyone who feels that they have a need to. (Of course, there are means to filter abusive people once they demonstrate their abuse, but there is no filter to the newcomer.) Had I known ietf@ietf.org was an email list, I wouldn't have emailed the list. However, having inadvertently done so, I hope I won't be accused of repeat mailbombing for sending this explanation in response to your accusation. If you'd like to suggest a way I can tell whether an email address represents a single individual or an email list, I'm all ears. In some circles, this is called due diligence. If I was requested to send an email about issue blah to someth...@foo.org, I would try and find at least something about foo.org. This could be done through a search engine, or by going to the appropriate web site. In our case, the first search item I found upon entering ietf@ietf.org into a common engine was https://www.ietf.org/mailman/listinfo/ietf which I think is pretty clear. For the direct approach, right on the home page there is a link marked "Mailing Lists," which (after the "Note Well" click through), takes you to a page http://www.ietf.org/maillist-new1.html which has a general description of the mailing lists, and a link to a description of the ietf@ietf.org list. Did you try either course ? If you did, and feel that you were confused about appropriate processes, I for one would like to hear about it. Many of these web pages are quite old, and there is certainly room for improvement. In my experience the IETF is very welcoming to new people and new points of view, but it can be hard to figure out what the pieces do in the beginning. If you want to continue, I would recommend that you start with the TAO, join the mailing lists of interest to you, and monitor the discussion for a while to get a feel of the local culture. Regards Marshall Eubanks Mark Rosenthal Noel Chiappa wrote: Thank you for being part of a crowd of hundreds of people who have mailbombed the mailboxes of thousands of IETF 'members' (since we don't have any formal membership, just an email list). As a result, we all have such positive feeling about the FSF. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: On the best use of IETF resources with respect to IPR
Paul Hoffman writes: >>I am aware that battle is already lost, so I have mixed feelings about >>discussing this further. > > ...so you launched dozens of people with much less understanding than > you into sending one-way comments on the topic. In the future, please > check your mix of feelings more carefully. Paul, I won't respond to the rest of your e-mail since I believe my position is already clear, however blaming me for the FSF campaign is unfair. I am not responsible for that. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Fwd: Re: Changes needed to Last Call boilerplate]
> From: Henk Uijterwaal > What is exactly the problem we're trying to solve here? Having people's mailboxes explode from ill-considered public pressure campaigns? At the start, I got as much email in one hour as I often get in a week. > Do we really want to introduce all kinds of complex procedures just > based on one incident? Well, it's not the first time - the FSF pulled the same stunt back in October of 2007. And no doubt, if it continues to be allowed, it will happen again. My original proposal was very simple: create one more list as a formal notice place for LC's, since many of the FSF drive-by posters were saying 'but, but your LC said send comments here'. Anyway, nothing is stopping an IETF person from sending email to the IETF list about something they want to bring up there, so if an LC has something that really bugs someone in the IETF, they can still send email to the IETF list about it. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07
On 2/12/09 4:47 PM, "Josh Howlett" wrote: > I have a long list of applications, collected from within this > community, with which they would like to use SAML-based authorisation; > and it seems to me that the ability for application protocols to share a > common mechanism for expressing authorisation would mitigate or perhaps > even avoid the need to make application-specific authorisation > extensions. Right, and to be more specific about it, the kinds of things that we're talking about include reducing retained state on devices during the authorization process by eliminating queries, reducing the problems around service discovery and topology, and I tend to think that there are some cross-domain advantages, as well. There are fate-sharing considerations, where the authorizations aren't held by devices that don't need them, they're not delivered if the traffic isn't delivered, and if the traffic is delivered the authorizations are delivered. So, I think that in addition to some issues specific to authorization problems there are some advantages around traditional networking considerations. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
On the best use of IETF resources with respect to IPR
At 12:57 PM +0100 2/13/09, Simon Josefsson wrote: >I believe it is possible to find proprietary licenses that have other >clauses that render the license incompatible with the IETF Trust >license. So the problem is wider than just free software licenses. I >believe the IETF needs to realize that GPL software runs part of the >Internet and that catering to these licensing needs is as important as >catering to the licensing needs of, say, Microsoft. I have not seen the IETF spend much time trying to cater to the licensing needs of, say, Microsoft. >The license compatibility question is more relevant for free software >because people are more conservative in evaluating software licenses in >the free software community compared to the enterprise setting where >licenses are typically only ever evaluated when someone sues or is sued >by someone. So, in essence, you are saying "because there is a community of developers who have a particular way of evaluating licenses, the IETF should spend a lot of time trying to cater to them". >My point has been that triggering this situation works counter to the >goal of the IETF. Please specifically state "the goal". I believe that you will find that it is, in fact, not a goal that is widely-held in the IETF. >In a strict setting, it means implementers cannot use >verbatim text from RFCs, s/implementers/a subset of implementers who have a particular way of evaluating licenses/ > but needs to rewrite the text to avoid re-use >of material under the IETF Trust license. I believe that opens up for >interoperability problems (when a re-written comment is subtly different >from the original meaning, and the comment influences code). If people >decide that this rewriting needs to happen to avoid contamination from >the IETF Trust license, it would also delay getting IETF protocols >deployed. ...by those developers. >This has been my rationale for suggesting that IETF documents should be >licensed under a free software compatible license. They are already licensed that way, for one common understanding of "free software compatible license". You have a different understanding for your purposes. You are (repeatedly) asking us to change our license for your understanding. >I am aware that >battle is already lost, so I have mixed feelings about discussing this >further. ...so you launched dozens of people with much less understanding than you into sending one-way comments on the topic. In the future, please check your mix of feelings more carefully. >Generally, however, I think this question is very different from where >this thread started. It started, as far as I consider, with Stephan >suggesting that free software authors publish "free" (as in licensed >under a free software license) standards in the IETF. That is not >possible ...by your interpretation, but clearly is possible by other people's interpretation... >, and is unrelated to the question we discuss here. I'm happy >to discuss both questions, but I'm concerned that you and others may >believe that you dispute my first claim by discussing this separate >issue. > >> With the GPL text, you don't have the copyright, and you don't have a >> license that permits modified versions. But you do have the right to >> copy it. >> >> With the excerpt from an RFC, you don't have the copyright, and you >> don't have a license that permits modified versions. But you do have >> the right to copy it - you even have the right to copy pieces of it. >> >> Why are you insisting that the first is perfectly reasonable, and the >> second is a show-stopper? > >I'm not saying the second is a show stopper. The Internet appears to >work relatively well on most days. However, I insist that it is a >potential impediment and that it works counter to the goals of the IETF. Your recent actions make it sound like you feel that it is a better use of IETF time to do work to make a subset of developers who have one particular view of licensing happy than to develop the technology we are good at. I propose that the opposite is true. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
(Re: IETF and open source license compatibility)
On Fri, 13 Feb 2009 12:57:02 +0100 Simon Josefsson wrote: >Harald Alvestrand writes: > >>> This seems more or less correct, even though it may sound surprising at >>> first. More generally, and more clearly expressed, it can be stated as >>> this: The license for a piece of work applies to the piece of work, it >>> does not apply to the license itself. The license of a work is not >>> normally not considered part of the work; it is metadata about the work. >>> >> But (and the reason why this is important, and IETF-relevant) how is >> this case different from the case where you introduce pieces of an RFC >> (which also don't need to be considered part of the work) as comments >> into a work? > >The only way I can see to avoid having the comment be part of the work >is to use different licenses for the code and the comment. (Do you see >any other way?) > >That is possible, but leads to problems. > >The result is a complex license on the combined work. The combined >license says essentially something like "License A applies to portion X >and the IETF Trust License applies to portion Y". That combined license >may not be compatible with other licenses, both free and non-free >licenses. > >For example, the combined license would not be compatible with the GPL >because modifications of the entire work is not permitted. > >I believe it is possible to find proprietary licenses that have other >clauses that render the license incompatible with the IETF Trust >license. So the problem is wider than just free software licenses. I >believe the IETF needs to realize that GPL software runs part of the >Internet and that catering to these licensing needs is as important as >catering to the licensing needs of, say, Microsoft. > >The license compatibility question is more relevant for free software >because people are more conservative in evaluating software licenses in >the free software community compared to the enterprise setting where >licenses are typically only ever evaluated when someone sues or is sued >by someone. > >My point has been that triggering this situation works counter to the >goal of the IETF. In a strict setting, it means implementers cannot use >verbatim text from RFCs, but needs to rewrite the text to avoid re-use >of material under the IETF Trust license. I believe that opens up for >interoperability problems (when a re-written comment is subtly different >from the original meaning, and the comment influences code). If people >decide that this rewriting needs to happen to avoid contamination from >the IETF Trust license, it would also delay getting IETF protocols >deployed. > >This has been my rationale for suggesting that IETF documents should be >licensed under a free software compatible license. I am aware that >battle is already lost, so I have mixed feelings about discussing this >further. However if others bring up related topics I feel a need to >respond. My hope is that it is possible to alter the policies in the >future. Fortunately, I believe the new BCP 78 has created good ground >to make that possible. > >Generally, however, I think this question is very different from where >this thread started. It started, as far as I consider, with Stephan >suggesting that free software authors publish "free" (as in licensed >under a free software license) standards in the IETF. That is not >possible, and is unrelated to the question we discuss here. I'm happy >to discuss both questions, but I'm concerned that you and others may >believe that you dispute my first claim by discussing this separate >issue. > >> With the GPL text, you don't have the copyright, and you don't have a >> license that permits modified versions. But you do have the right to >> copy it. >> >> With the excerpt from an RFC, you don't have the copyright, and you >> don't have a license that permits modified versions. But you do have >> the right to copy it - you even have the right to copy pieces of it. >> >> Why are you insisting that the first is perfectly reasonable, and the >> second is a show-stopper? > >I'm not saying the second is a show stopper. The Internet appears to >work relatively well on most days. However, I insist that it is a >potential impediment and that it works counter to the goals of the IETF. > This kind of complexity will end up having all kinds of unfortunate consequences. To give but one example I do some development work for Debian and Ubuntu (a major derivative of Ubuntu). Debian has a long standing policy on licensing requirements for inclusion of software in Debian (I'm not asking you to accept any value judgements about the goodness or badness of these requiements, they are what they are). One requirement is that the work be freely modifiable. As a result, RFCs and IETF drafts are not acceptable. Any substantial quote that carried the same licensing requirements would have to be removed. Another requirement is that software sources be shipped in their prefe
Re: Including the GPL in GPL code (Re: IETF and open source license compatibility)
Harald Alvestrand wrote: Simon, the example is at http://counter.li.org/scripts/machine-update. Take a look. There is a single file that contains both the program source and the GPL. I want to release this under the GPL. Now, I have three possible interpretations: 1 - The words of the GPL that say "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." don't really apply in this case. 2 - The words of the GPL that say "You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above" don't apply to modifications of the portion of the Program that is the GPL 3 - I'm breaking the GPL Now, with your extensive knowledge of what the GPL means for included text which is it? 4 - The contradiction in licensing terms turns the work licensed by its own terms, that are not exactly those of the GPL. Furthermore, the original copyright holder breached the GPL *text* copyright. He did not breached the GPL itself since he is the original author of the work. The intent of the original copyright holder is clear however, despite a minor glith in document distribution. Simon and I and anyone else who whish to create derivative works under the GPL can fix it, and not carry forward the contradiction in licensing terms (the Harald intent above is not clear, the referenced work is not his work, and it is already released). Anyway, Harald highlighted a corner case in GPL licensing that creates some inconvenience (can't put GPL text in GPL'ed work, it must remain meta-data). IETF as a *document* editor is expected to use licensing terms that reasonably fits its purpose. The audience lobbyed by Simon should just live by inconvenience created by IETF licensing terms (no RFC text in GPL'ed software beyond fair use - it must remain as separate documentation). Routine open software distribution abide by these rules. Please preserve the integrity of IETF rules addressing the needs of a broader and a more diversified audience than the one lobbied by Simon. Regards, -- - Thierry Moreau ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Including the GPL in GPL code (Re: IETF and open source license compatibility)
writes: > Simon Josefsson wrote: > >> Generally, however, I think this question is very different from where >> this thread started. It started, as far as I consider, with Stephan >> suggesting that free software authors publish "free" (as in licensed >> under a free software license) standards in the IETF. That is not >> possible, and is unrelated to the question we discuss here. > > BTW, why cannot a free software author license some particular > standards text under both RFC 5378 terms, and some other license > (a free software license, or even GPL)? > > Presumably, he/she owns the copyright, and 5378 terms are > non-exclusive. Obviously, for collaborative efforts this may require > that all copyright holders agree, and that may make this unpractical. > But I wonder if there was some other reason? No, that approach works fine as far as I can see. It has been used for some documents, and parts of some documents, already. That doesn't make the standard published by the IETF "free" as in free software licensed though. I admit this is a subtle distinction, and given the discussion, I must have explained this poorly. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Including the GPL in GPL code (Re: IETF and open source license compatibility)
Simon Josefsson wrote: > Generally, however, I think this question is very different from where > this thread started. It started, as far as I consider, with Stephan > suggesting that free software authors publish "free" (as in licensed > under a free software license) standards in the IETF. That is not > possible, and is unrelated to the question we discuss here. BTW, why cannot a free software author license some particular standards text under both RFC 5378 terms, and some other license (a free software license, or even GPL)? Presumably, he/she owns the copyright, and 5378 terms are non-exclusive. Obviously, for collaborative efforts this may require that all copyright holders agree, and that may make this unpractical. But I wonder if there was some other reason? Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you install Mail Filters how is the list integrity to be documented?
Sam Hartman wrote: >> "TSG" == TSG writes: > > TSG> There is a serious concern that when individuals are > TSG> 'filtered out of IETF lists' whether by official or > TSG> unofficial means, that their voices are prevented from being > TSG> included into the IETF standards process. > > I'd feel this issue was a higher priority if the people who are being > filtered had written internet drafts. > > I definitely think that we should be very careful about filtering > internet draft submissions. > > I think that if someone writes a credible internet draft that we need > to make sure that it receives appropriate discussion. I vaguely remember draft-jefsey-mltf-cctags but nevertehless I remember Jefsey Morfin beeing banned. How about draft-anderson-reverse-dns-status and Dean Anderson? I cannot rid myself of the feeling that non english speakers do have a little problem and non latin writers do have a big problem to express their views in IETF. And there are both financial and political interests too. We have left a decade with no need for communication with opposite ideas behind us. It is a wonder that IETF survived. Today we talk again to each other. I am glad the IETF survived. Or seen the other way round - what happened to ISODE? The ISO code was not free so people preferred to stay with tcp/ip and IPv4. Now we are talking about IPv6. ISO never made it. Yes, all that guys shouting me too and filling my mailbox is annoying. It would be so easy to cancel my subscription. No I won't. I'll stay on the list. Kind regards Peter -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: pe...@peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
On Fri, 13 Feb 2009 11:48:08 +0100 Simon Josefsson wrote: > "Steven M. Bellovin" writes: > > > On Thu, 12 Feb 2009 21:38:44 +0100 > > Simon Josefsson wrote: > > > >> The discussion started by Stephan suggesting that free software > >> authors publish their work as free standards in the IETF. My point > >> was that since the IETF disallow publishing standards under a > >> license that is compatible with free software licensing (e.g., > >> allows modification), it is not possible for free software authors > >> to do this. Thus, to me, this discussion is not related to > >> comments in source code at all. > > > > My understanding of IETF policy is that the IETF will publish I-Ds > > that are in the public domain. Nothing is freer than that. You're > > perfectly free to put your text in the public domain before > > submitting it for publication as an RFC. > > Sure, but I can also put the text under the Microsoft EULA before > submitting it for publication as an RFC. The IETF still requires some > assurances from me as contributor, and those assurances go beyond both > what the public domain and the Microsoft EULA implies. > > A more interesting question is if you can submit somebody else's > public domain work to the IETF. I don't know the answer to that. Legally, yes; it's public domain. Academic honesty and common courtesy would demand an acknowledgment. > It > seems clear that I can't take a work licensed under the Microsoft > EULA and submit it to the IETF though. > Right, which is why I suggested public domain and not the Microsoft EULA More generally: if the goal is to have some text that can be freely used in any software -- proprietary, open source, GPL -- there's nothing more amenable to that than public domain. That may not meet all of the FSF's goals, but I don't really see that that's the IETF's problem. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
> > A more interesting question is if you can submit somebody else's > > public domain work to the IETF. I don't know the answer to that. > > Legally, yes; it's public domain. Academic honesty and common courtesy > would demand an acknowledgment. more than that - the standards process requires an acknowledgment of all significant contributers so an acknowledgment is required Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: TLS WG Chair Comments on draft-ietf-tls-authz-07
Michael StJohns wrote: > I went to review the bidding on the TLS mailing list covering this > period and it appears the archives at > http://www.ietf.org/mail-archive/web/tls/current/maillist.html only > go back to the beginning of the year. Could you point me at a more > complete archive covering the period and the discussions about TLS > WG interest in this document please? I'm not sure if you already got an answer to this question (following the mailing list hasn't been easy :-), but... The archives at http://www.ietf.org/mail-archive/web/tls/current/maillist.html go back to September 2004 (just keep clicking the "Next Page" link -- and yes, I agree that the user interface could be better). That should cover this draft's life span (version -00 is from 2006). If you're interested in more ancient history, the following links may (or may not) be useful: http://www.ietf.org/mail-archive/text/tls/ http://lists.w3.org/Archives/Public/ietf-tls/ Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: LORAN is making a comeback..
How about a workgroup and a mailinglist? Maybe it has nothing to do with IETF it definitely has to do with DTN, UDP, IPv6 and BEHAVE. I am interested. Peter Lyndon Nerenberg wrote: > Take it off line. This has nothing to do with the IETF. > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: pe...@peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Including the GPL in GPL code (Re: IETF and open source license compatibility)
Harald Alvestrand writes: >> This seems more or less correct, even though it may sound surprising at >> first. More generally, and more clearly expressed, it can be stated as >> this: The license for a piece of work applies to the piece of work, it >> does not apply to the license itself. The license of a work is not >> normally not considered part of the work; it is metadata about the work. >> > But (and the reason why this is important, and IETF-relevant) how is > this case different from the case where you introduce pieces of an RFC > (which also don't need to be considered part of the work) as comments > into a work? The only way I can see to avoid having the comment be part of the work is to use different licenses for the code and the comment. (Do you see any other way?) That is possible, but leads to problems. The result is a complex license on the combined work. The combined license says essentially something like "License A applies to portion X and the IETF Trust License applies to portion Y". That combined license may not be compatible with other licenses, both free and non-free licenses. For example, the combined license would not be compatible with the GPL because modifications of the entire work is not permitted. I believe it is possible to find proprietary licenses that have other clauses that render the license incompatible with the IETF Trust license. So the problem is wider than just free software licenses. I believe the IETF needs to realize that GPL software runs part of the Internet and that catering to these licensing needs is as important as catering to the licensing needs of, say, Microsoft. The license compatibility question is more relevant for free software because people are more conservative in evaluating software licenses in the free software community compared to the enterprise setting where licenses are typically only ever evaluated when someone sues or is sued by someone. My point has been that triggering this situation works counter to the goal of the IETF. In a strict setting, it means implementers cannot use verbatim text from RFCs, but needs to rewrite the text to avoid re-use of material under the IETF Trust license. I believe that opens up for interoperability problems (when a re-written comment is subtly different from the original meaning, and the comment influences code). If people decide that this rewriting needs to happen to avoid contamination from the IETF Trust license, it would also delay getting IETF protocols deployed. This has been my rationale for suggesting that IETF documents should be licensed under a free software compatible license. I am aware that battle is already lost, so I have mixed feelings about discussing this further. However if others bring up related topics I feel a need to respond. My hope is that it is possible to alter the policies in the future. Fortunately, I believe the new BCP 78 has created good ground to make that possible. Generally, however, I think this question is very different from where this thread started. It started, as far as I consider, with Stephan suggesting that free software authors publish "free" (as in licensed under a free software license) standards in the IETF. That is not possible, and is unrelated to the question we discuss here. I'm happy to discuss both questions, but I'm concerned that you and others may believe that you dispute my first claim by discussing this separate issue. > With the GPL text, you don't have the copyright, and you don't have a > license that permits modified versions. But you do have the right to > copy it. > > With the excerpt from an RFC, you don't have the copyright, and you > don't have a license that permits modified versions. But you do have > the right to copy it - you even have the right to copy pieces of it. > > Why are you insisting that the first is perfectly reasonable, and the > second is a show-stopper? I'm not saying the second is a show stopper. The Internet appears to work relatively well on most days. However, I insist that it is a potential impediment and that it works counter to the goals of the IETF. But to answer your question (heh!): I believe the situations are different because the first is about meta-data of a work, and the second results in a complex combined license. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Including the GPL in GPL code (Re: IETF and open source license compatibility)
Simon Josefsson wrote: This is getting off-topic, and seems like typical FAQ material, but I'll reply briefly. I suggest using, e.g., discuss...@fsfeurope.org to get other people's interpretations. If you want a more authoritative answer, talk to licens...@gnu.org. 2 - The words of the GPL that say "You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above" don't apply to modifications of the portion of the Program that is the GPL This seems more or less correct, even though it may sound surprising at first. More generally, and more clearly expressed, it can be stated as this: The license for a piece of work applies to the piece of work, it does not apply to the license itself. The license of a work is not normally not considered part of the work; it is metadata about the work. But (and the reason why this is important, and IETF-relevant) how is this case different from the case where you introduce pieces of an RFC (which also don't need to be considered part of the work) as comments into a work? With the GPL text, you don't have the copyright, and you don't have a license that permits modified versions. But you do have the right to copy it. With the excerpt from an RFC, you don't have the copyright, and you don't have a license that permits modified versions. But you do have the right to copy it - you even have the right to copy pieces of it. Why are you insisting that the first is perfectly reasonable, and the second is a show-stopper? Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Including the GPL in GPL code (Re: IETF and open source license compatibility)
This is getting off-topic, and seems like typical FAQ material, but I'll reply briefly. I suggest using, e.g., discuss...@fsfeurope.org to get other people's interpretations. If you want a more authoritative answer, talk to licens...@gnu.org. Harald Alvestrand writes: >>> BTW, this means that at least one program I have released under the >>> GPL is illegal; it includes the GPL as a part of the source code, and >>> since the GPL text is immutable according to the GPL, it is illegal >>> (by this logic) to include it in source code, since the source has to >>> be free of restrictions upon its modification. >>> >> >> I don't see how that makes the program illegal. It just makes it harder >> for others to redistribute it safely because the licensing information >> is unclear. > Simon, > > the example is at http://counter.li.org/scripts/machine-update. Take a look. > > There is a single file that contains both the program source and the GPL. > I want to release this under the GPL. You can't release the text of the GPL under the GPL license, since you are not the copyright holder of the text in the GPL license. Further, the license of the GPL text does not permit re-licensing, or even modifications. > Now, I have three possible interpretations: > > 1 - The words of the GPL that say "Everyone is permitted to copy and > distribute verbatim copies of this license document, but changing it > is not allowed." don't really apply in this case. That interpretation seems clearly bogus to me. > 2 - The words of the GPL that say "You may modify your copy or copies > of the Program or any portion of it, thus forming a work based on the > Program, and copy and distribute such modifications or work under the > terms of Section 1 above" don't apply to modifications of the portion > of the Program that is the GPL This seems more or less correct, even though it may sound surprising at first. More generally, and more clearly expressed, it can be stated as this: The license for a piece of work applies to the piece of work, it does not apply to the license itself. The license of a work is not normally not considered part of the work; it is metadata about the work. > 3 - I'm breaking the GPL That may hold as well, but without further elaboration I can't tell for sure. I compared the part of your work that consists of the GPL text with the canonical version [1]. It seems that someone has modified the license text: the section 'How to Apply These Terms to Your New Programs' is missing. If you had read that section, you would know of a better way to explain the licensing conditions to users that would have avoided the problem. I believe this violate the license on the GPL itself, so you may want to fix it. However, I don't think the FSF will care significantly about that problem. For more information, see: http://www.gnu.org/licenses/gpl-howto.html > Now, with your extensive knowledge of what the GPL means for included > text which is it? Your question comes up and is answered in Debian mailing lists from time to time: some people claim that Debian cannot distribute the GPL license text because it is not licensed under a free software license. /Simon [1] http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: LORAN is making a comeback..
Lyndon Nerenberg a écrit : Take it off line. This has nothing to do with the IETF. I think this may be relevant to IETF. I'm discovering LORAN, and there seems to be a foo channel over which IP could run. Maybe also LORAN-specific data could be encoded in UDP payloads. Maybe Geopriv WG could be relevant too. Alex ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
"Steven M. Bellovin" writes: > On Thu, 12 Feb 2009 21:38:44 +0100 > Simon Josefsson wrote: > >> The discussion started by Stephan suggesting that free software >> authors publish their work as free standards in the IETF. My point >> was that since the IETF disallow publishing standards under a license >> that is compatible with free software licensing (e.g., allows >> modification), it is not possible for free software authors to do >> this. Thus, to me, this discussion is not related to comments in >> source code at all. > > My understanding of IETF policy is that the IETF will publish I-Ds that > are in the public domain. Nothing is freer than that. You're > perfectly free to put your text in the public domain before submitting > it for publication as an RFC. Sure, but I can also put the text under the Microsoft EULA before submitting it for publication as an RFC. The IETF still requires some assurances from me as contributor, and those assurances go beyond both what the public domain and the Microsoft EULA implies. A more interesting question is if you can submit somebody else's public domain work to the IETF. I don't know the answer to that. It seems clear that I can't take a work licensed under the Microsoft EULA and submit it to the IETF though. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
Simon Josefsson wrote: Nobody forces you to use the GPL, so if you perceive a problem I suggest to use another license for your program. Unless your starting code is using the GPL, then you are forced to use the GPL and are not *free* to use any other license without permission from the copyright holder(s). Ironic. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Including the GPL in GPL code (Re: IETF and open source license compatibility)
Simon Josefsson wrote: I consider the inability to include immutable text in software released under the GPL a bug in the GPL. Nobody forces you to use the GPL, so if you perceive a problem I suggest to use another license for your program. However, the IETF should not prevent implementers from using the GPL, for the same reasons IETF should not prevent Microsoft from using its EULA as the license. BTW, this means that at least one program I have released under the GPL is illegal; it includes the GPL as a part of the source code, and since the GPL text is immutable according to the GPL, it is illegal (by this logic) to include it in source code, since the source has to be free of restrictions upon its modification. I don't see how that makes the program illegal. It just makes it harder for others to redistribute it safely because the licensing information is unclear. Simon, the example is at http://counter.li.org/scripts/machine-update. Take a look. There is a single file that contains both the program source and the GPL. I want to release this under the GPL. Now, I have three possible interpretations: 1 - The words of the GPL that say "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed." don't really apply in this case. 2 - The words of the GPL that say "You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above" don't apply to modifications of the portion of the Program that is the GPL 3 - I'm breaking the GPL Now, with your extensive knowledge of what the GPL means for included text which is it? Harald ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF and open source license compatibility
Harald Alvestrand writes: > Simon Josefsson wrote: >>> >>> actually that's intended to be permitted by RFC 5377 section 4.2: >>> >>> 4.2. Rights Granted for Quoting from IETF Contributions >>> >>> There is rough consensus that it is useful to permit quoting without >>> modification of excerpts from IETF Contributions. Such excerpts may >>> be of any length and in any context. Translation of quotations is >>> also to be permitted. All such quotations should be attributed >>> properly to the IETF and the IETF Contribution from which they are >>> taken. >>> >>> You're not permitted to modify the text. You are permitted to use it. >>> >> >> Exactly, and disallowing modifications prevents using the text of an RFC >> as a comment in implementations licensed under free software licenses. >> >> For short excerpts, one can use the text anyway and claim "fair use", >> but larger excerpts can be useful to quote in comments or documentation >> and then there is a problem. > I consider the inability to include immutable text in software > released under the GPL a bug in the GPL. Nobody forces you to use the GPL, so if you perceive a problem I suggest to use another license for your program. However, the IETF should not prevent implementers from using the GPL, for the same reasons IETF should not prevent Microsoft from using its EULA as the license. > BTW, this means that at least one program I have released under the > GPL is illegal; it includes the GPL as a part of the source code, and > since the GPL text is immutable according to the GPL, it is illegal > (by this logic) to include it in source code, since the source has to > be free of restrictions upon its modification. I don't see how that makes the program illegal. It just makes it harder for others to redistribute it safely because the licensing information is unclear. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Changes needed to Last Call boilerplate
> > (For "Members of the IETF" we can substitute "People who are subscribed to > the IETF Discussion list", if people think that is needed in place of the > technically somewhat nebulous "Members of the IETF".) > If you really want to limit it to people subscribed to the list, forget the boilerplate, just configure Mailman differently. With the text above, don't be surprised when people learn that they can become bona fide IETF members by subscribing to the IETF discussion list and the new subscription volume swells exponentially. Given the contents of many of the letters received on the patent issue, I would expect the majority of those people to be willing, and capable of, subscribing to the IETF list in order to submit a comment. Also, don't be surprised when the next time this issue arises, the FSF encourages people to join the IETF WG discussing the next patent-encumbered draft. Fundamentally, the IETF is a legislative body crafting legislation that allows people to share intellectual property confident that they have the legal right to do so and that the risks from such sharing are minimized. Lobbying is fundamental to lawmaking. The roots of the IETF process are in the 1960's when people enhanced western democratic models with native American democratic models in which all voices are heard. Perhaps the solution to this type of issue is to solicit those voices earlier in the process, and then if there is no consensus, drop any further discussion of the draft. Patent issues affect more than just the select few who participate in IETF WGs and meetings. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07
Sam Hartman wrote: > The Kerberos community has many years of experience that > within an infrastructure, carrying authorizations in-band has > been useful and has reduced the effort required to fit an > application into a larger infrastructure. Just a quick plug, following Sam's comments: augmenting Kerberos with SAML is one of the possibilities discussed within a paper that was recently published by the MIT Kerberos Consortium. http://kerberos.org/software/kerbweb.pdf josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [TLS] TLS WG Chair Comments on draft-ietf-tls-authz-07
Hi Hans, > >Hannes wrote: > >> Melinda wrote: > >> > > >> > and that there are > >> > some non-trivial advantages to carrying authorizations in-band. > >> Namely... > > > >I don't wish to speak for Melinda, but this is a view shared by many > >within my own community. > > > >I have a long list of applications, collected from within this > >community, with which they would like to use SAML-based > authorisation; > > Interesting. Any interest to share it with us? I'm in the process of trying to flesh it out at the moment, in a collaboration with some of the communities concerned, so that we can articulate some concrete use-cases. At the moment the list covers pretty much everything that is presently used in an Inter-Institutional context (AFS, SSH, VNC, RDP, SIP, SMTP, NEA, ...). > >and it seems to me that the ability for application > protocols to share > >a common mechanism for expressing authorisation would mitigate or > >perhaps even avoid the need to make application-specific > authorisation > >extensions. > > My experience: authorization is often related to the specific > application domain. I agree insofar as 'authorisation' is often an exercise in making statements using semantics that are specific to application domains, but I don't believe it follows that the syntactical and transport elements (that support the semantic expression) also need to be specific to the application domain. > Furthermore, working on SIP SAML I noticed the problems when > you go down to specific solutions scenarios. Can you expand? > >(The fact that SAML-based Web SSO uses SAML that is bound to the > >application-layer is, I believe, only an artifact of a > requirement to > >avoid modifying contemporary Web browsers and I don't think it is an > >approach that would necessarily be desirable for the general case.) > > ... a reasonable transition plan, in my view. Sure. > The reason for the success of these IdM solutions, > particularly OpenID. (Well - OpenID has been a flop in my opinion. It has its uses, but not very interesting ones. But I digress...) > >Binding authorisation to TLS, as suggested by this document, is one > >approach that would satisfy the 'common mechanism' > >requirement indicated previously. > > Looking forward to see your solutions. I have no answers; I'm still trying to figure out what the questions are :-/ josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
[Fwd: Re: Changes needed to Last Call boilerplate]
Noel Chiappa wrote: (Discussion deleted) I think these (and the per-draft mailboxes others have mentioned) are probably all steps in a long-term plan, with the eventual optimum system being the web-based thing you mention. What is exactly the problem we're trying to solve here? I think most of us like to see LC comments related to the drafts that they are somehow involved with (author, WG participant, etc). Posting those comments to the ietf list takes care of that, without work or effort from anybody. Most of the 250+ drafts that go last call every year, generate no comments on the list. The TLS draft is an exception with 100's of replies. However, I cannot remember any similar cases in the last 10 years. Pressing delete 100 times worked for me, that is a few minutes of work in a 10 year period, in other words no work at all. Do we really want to introduce all kinds of complex procedures just based on one incident? Henk -- -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. -- -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- Belgium: an unsolvable problem, discussed in endless meetings, with no hope for a solution, where everybody still lives happily. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Changes needed to Last Call boilerplate
Moin! On 13.02.2009, at 03:34, Willie Gillespie wrote: Not a bad idea. In fact, it may be useful to have a unique "list" per draft, so every comment relating to a particular draft can be tracked historically. This example is how I understand your suggestion: ietf+housley-tls-authz-ex...@ietf.org will automatically be set up with the initial ID submission. E-mails sent to it will be regarded as discussion pertaining to the draft. Individuals interested in following the draft may subscribe to that list simply by sending an e-mail to it. (However, e-mails with simply the word "subscribe" in the body or subject line won't be forwarded to everyone.) They are also allowed to unsubscribe (perhaps following the 48-hour waiting period of initial subscription as David suggested). Note also that e-mails sent to ietf+draft-n...@ietf.org would not be sent to the general list of i...@ietf.org. I strongly disagree with that proposal. Some points only come up in the discussions about a draft. So if I hadn't subscribed to the draft mail list I would not become aware of that. I can see a point distinguishing between subscribers and non-subscribers to ietf@ietf.org, but what you are proposing here is like the working group emails list we have now and not what ietf@ietf.org is about. So long -Ralf --- Ralf Weber Platform Infrastructure Manager Colt Telecom GmbH Herriotstrasse 4 60528 Frankfurt Germany DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780 Fax: +49 (0)69 56606 6280 Email: r...@colt.net http://www.colt.net/ Data | Voice | Managed Services Schütze Deine Umwelt | Erst denken, dann drucken * COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland * Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 * Geschäftsführer: Dr. Jürgen Hernichel (Vors.), Rita Thies * Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
