Re: Oppose draft-carpenter-ipr-patent-frswds-00
At 04:24 AM 10/30/2007, Simon Josefsson wrote: > At 04:48 PM 10/29/2007, Simon Josefsson wrote: >>"Eric Burger" <[EMAIL PROTECTED]> writes: >> >> > One interesting side effect of the existence of an open source >> > implementation of a protocol is monoculture. We ran into a problem in >> > ifax year ago when it turned out that all eight "independent" >> > implementations all relied on the same library, thus rendering the >> > "independent" implementations label difficult, to say the least. Why >> > were there no independent implementations? Because in this case, the >> > open source implementation was pretty good, and it was not worth >> > investing in a proprietary implementation. The result here has a really >> > bad side effect for the IETF: if there is a good open source, free >> > implementation, there will be no second implementation, resulting in it >> > being impossible for the standard to progress. >> >>But that is how it is supposed to work! If there is only one >>implementation, a standard is not mature enough to move to DS. You need >>to have at least two, preferably several more, completely independent >>implementations in order to quality-test a standard. > > but why does one or both have to be open source? > > Why can't both be commercial? DS designates a mature standard. If you read the requirements in RFC 2026 for a mature standard it is clear that few of the modern IETF protocols live up to that standard -- you need to demonstrate interoperability between two completely independent implementations of _all_ features in the protocol standard. Another (existing) requirement is that any patent licenses needs to be obtained through separate processes. I believe that a good way to demonstrate that the patent license process works is to require that a free software implementation exists. I strongly believe it should be possible to participate on the Internet without paying a software patent tax to some organizations. I believe you are arguing that the ends justify the means. In other words, because all the licensing has to be worked out (to become a DS), you believe a free implementation is the answer. I say it is not. Two commercial organizations can work out licensing and comply with this requirement - but you don't want that to be acceptable. I hold that this is what I'm referring to as "bad for the IETF" because corporations will either start involving themselves less in the IETF (directly affecting the IETF's revenue - which is already too low, and probably adversely affecting corporate sponsorship of meetings - which is already hard to acquire), and/or have fewer corporate participants care about DS and FS RFCs, because there is no incentive for them to do the work. BTW - if you believe a free (cost-wise) implementation be mandatory for elevation to DS, why don't you suggest the text be changed to say that? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Oppose draft-carpenter-ipr-patent-frswds-00
At 04:24 AM 10/30/2007, Simon Josefsson wrote: > I admit now s/now/not all PSs have IPR attached, but this is almost certainly > intended to kill any IPR from achieving DS. Is that what is intended > here? I don't believe that was the intention, but that's a question for Brian. I disagree that all PSs are patented (if that is what you meant). see above - I misspelled a word that means something else. sorry I've implemented several such standards without worrying about patents. I believe the majority of PSs are actually published without known patents. A search in the IETF IPR tracker should answer that. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Oppose draft-carpenter-ipr-patent-frswds-00
"James M. Polk" <[EMAIL PROTECTED]> writes: > At 04:48 PM 10/29/2007, Simon Josefsson wrote: >>"Eric Burger" <[EMAIL PROTECTED]> writes: >> >> > One interesting side effect of the existence of an open source >> > implementation of a protocol is monoculture. We ran into a problem in >> > ifax year ago when it turned out that all eight "independent" >> > implementations all relied on the same library, thus rendering the >> > "independent" implementations label difficult, to say the least. Why >> > were there no independent implementations? Because in this case, the >> > open source implementation was pretty good, and it was not worth >> > investing in a proprietary implementation. The result here has a really >> > bad side effect for the IETF: if there is a good open source, free >> > implementation, there will be no second implementation, resulting in it >> > being impossible for the standard to progress. >> >>But that is how it is supposed to work! If there is only one >>implementation, a standard is not mature enough to move to DS. You need >>to have at least two, preferably several more, completely independent >>implementations in order to quality-test a standard. > > but why does one or both have to be open source? > > Why can't both be commercial? DS designates a mature standard. If you read the requirements in RFC 2026 for a mature standard it is clear that few of the modern IETF protocols live up to that standard -- you need to demonstrate interoperability between two completely independent implementations of _all_ features in the protocol standard. Another (existing) requirement is that any patent licenses needs to be obtained through separate processes. I believe that a good way to demonstrate that the patent license process works is to require that a free software implementation exists. I strongly believe it should be possible to participate on the Internet without paying a software patent tax to some organizations. > So few PSs become DSs, I believe this will almost certainly make > progression from PS to DS slower. Is that what we want? I believe it will lead to better quality DS standards. The reason few PSs become DSs is, in my experience, not because a lack of free implementations, but rather that nobody cares enough to go through the pain of interop testing. The requirements for DS are pretty high already, which can be discussed as a separate issue, but this draft is only a marginal change. My impression is that your problem really is that few documents move to DS, not that a free implementation should be required. > I admit now all PSs have IPR attached, but this is almost certainly > intended to kill any IPR from achieving DS. Is that what is intended > here? I don't believe that was the intention, but that's a question for Brian. I disagree that all PSs are patented (if that is what you meant). I've implemented several such standards without worrying about patents. I believe the majority of PSs are actually published without known patents. A search in the IETF IPR tracker should answer that. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Oppose draft-carpenter-ipr-patent-frswds-00
At 04:48 PM 10/29/2007, Simon Josefsson wrote: "Eric Burger" <[EMAIL PROTECTED]> writes: > One interesting side effect of the existence of an open source > implementation of a protocol is monoculture. We ran into a problem in > ifax year ago when it turned out that all eight "independent" > implementations all relied on the same library, thus rendering the > "independent" implementations label difficult, to say the least. Why > were there no independent implementations? Because in this case, the > open source implementation was pretty good, and it was not worth > investing in a proprietary implementation. The result here has a really > bad side effect for the IETF: if there is a good open source, free > implementation, there will be no second implementation, resulting in it > being impossible for the standard to progress. But that is how it is supposed to work! If there is only one implementation, a standard is not mature enough to move to DS. You need to have at least two, preferably several more, completely independent implementations in order to quality-test a standard. but why does one or both have to be open source? Why can't both be commercial? So few PSs become DSs, I believe this will almost certainly make progression from PS to DS slower. Is that what we want? I admit now all PSs have IPR attached, but this is almost certainly intended to kill any IPR from achieving DS. Is that what is intended here? /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Oppose draft-carpenter-ipr-patent-frswds-00
"Eric Burger" <[EMAIL PROTECTED]> writes: > One interesting side effect of the existence of an open source > implementation of a protocol is monoculture. We ran into a problem in > ifax year ago when it turned out that all eight "independent" > implementations all relied on the same library, thus rendering the > "independent" implementations label difficult, to say the least. Why > were there no independent implementations? Because in this case, the > open source implementation was pretty good, and it was not worth > investing in a proprietary implementation. The result here has a really > bad side effect for the IETF: if there is a good open source, free > implementation, there will be no second implementation, resulting in it > being impossible for the standard to progress. But that is how it is supposed to work! If there is only one implementation, a standard is not mature enough to move to DS. You need to have at least two, preferably several more, completely independent implementations in order to quality-test a standard. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Oppose draft-carpenter-ipr-patent-frswds-00
Although this may not be a popular opinion, I have to agree with James here. Our goal is to have the widest acceptance of a given protocol output from the IETF. One way is to have lots of open source implementations. One interesting side effect of the existence of an open source implementation of a protocol is monoculture. We ran into a problem in ifax year ago when it turned out that all eight "independent" implementations all relied on the same library, thus rendering the "independent" implementations label difficult, to say the least. Why were there no independent implementations? Because in this case, the open source implementation was pretty good, and it was not worth investing in a proprietary implementation. The result here has a really bad side effect for the IETF: if there is a good open source, free implementation, there will be no second implementation, resulting in it being impossible for the standard to progress. We are the IETF and not the Open Source Consortium. I would offer we focus on producing the best and most spreadable protocols. That hints at, but does not require, open source. If one wants open source, participate in one or more of the most excellent open source communities and forums. -- Eric Burger Member of the Board of the SIP Forum, which has a charter to support Open Source, as well as commercial, implementations -Original Message- From: James M. Polk [mailto:[EMAIL PROTECTED] Sent: Monday, October 29, 2007 3:20 PM To: ietf@ietf.org Subject: Oppose draft-carpenter-ipr-patent-frswds-00 http://www.ietf.org/internet-drafts/draft-carpenter-ipr-patent-frswds-00 .txt offers this text as a modification to RFC 2026: A specification from which at least two independent and interoperable implementations from different code bases have been developed, of which at least one is available as free software, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. I oppose this text in any IETF document because it is counter to vendor implementations (*any* vendor implementations) to achieve Draft Standard status of a document, and that's bad for the IETF. For example, take two vendors: Vendor-A and Vendor-B. One of the vendor's has legitimate IPR claims on a PS RFC, the other either has a license on that IPR from the inventing vendor, or has implemented it under the IPR claim's royalty-free IPR statement (just as some IPR has in its claim into the IETF). Some PS RFCs are either very little used or very complicated, meaning they aren't very popular (to the Open Source community) or cost to much (time/money) to develop. So unless someone decides to do the work anyway (which doesn't make sense to require) - the suggested text above prevents both Vendor-A's and Vendor-B's implementations from being considered for elevation of this PS RFC to DS RFC *because* they (for some crazy reason) want to charge money for the products where this implementation can be utilized. BTW - isn't charging money for products how vendor's stay in business? The IETF preventing vendors from making money in order for the IETF to consider progressing a PS RFC to DS RFC is completely counterintuitive and will reduce vendor participation in the IETF. As much as some might applaud that result, it will mean either the demise of the IETF (without sponsors and vendor participants attending meetings to pay the bills), or that everything is just fine as a PS - which makes the suggested text above completely useless. James ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Oppose draft-carpenter-ipr-patent-frswds-00
Could we discuss this over on the IPR WG list, since the draft responds to a specific request from the WG Chair? Brian On 2007-10-30 08:44, Henning Schulzrinne wrote: I admit to finding the discussion about Draft standards a bit theoretical, given how few RFCs ever make it there. As a rough estimate, http://www.rfc-editor.org/rfcxx00.html#Draft shows a rate of 20 out of a 1000. On Oct 29, 2007, at 3:20 PM, James M. Polk wrote: http://www.ietf.org/internet-drafts/draft-carpenter-ipr-patent-frswds-00.txt offers this text as a modification to RFC 2026: A specification from which at least two independent and interoperable implementations from different code bases have been developed, of which at least one is available as free software, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. I oppose this text in any IETF document because it is counter to vendor implementations (*any* vendor implementations) to achieve Draft Standard status of a document, and that's bad for the IETF. For example, take two vendors: Vendor-A and Vendor-B. One of the vendor's has legitimate IPR claims on a PS RFC, the other either has a license on that IPR from the inventing vendor, or has implemented it under the IPR claim's royalty-free IPR statement (just as some IPR has in its claim into the IETF). Some PS RFCs are either very little used or very complicated, meaning they aren't very popular (to the Open Source community) or cost to much (time/money) to develop. So unless someone decides to do the work anyway (which doesn't make sense to require) - the suggested text above prevents both Vendor-A's and Vendor-B's implementations from being considered for elevation of this PS RFC to DS RFC *because* they (for some crazy reason) want to charge money for the products where this implementation can be utilized. BTW - isn't charging money for products how vendor's stay in business? The IETF preventing vendors from making money in order for the IETF to consider progressing a PS RFC to DS RFC is completely counterintuitive and will reduce vendor participation in the IETF. As much as some might applaud that result, it will mean either the demise of the IETF (without sponsors and vendor participants attending meetings to pay the bills), or that everything is just fine as a PS - which makes the suggested text above completely useless. James ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Oppose draft-carpenter-ipr-patent-frswds-00
I admit to finding the discussion about Draft standards a bit theoretical, given how few RFCs ever make it there. As a rough estimate, http://www.rfc-editor.org/rfcxx00.html#Draft shows a rate of 20 out of a 1000. On Oct 29, 2007, at 3:20 PM, James M. Polk wrote: http://www.ietf.org/internet-drafts/draft-carpenter-ipr-patent- frswds-00.txt offers this text as a modification to RFC 2026: A specification from which at least two independent and interoperable implementations from different code bases have been developed, of which at least one is available as free software, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. I oppose this text in any IETF document because it is counter to vendor implementations (*any* vendor implementations) to achieve Draft Standard status of a document, and that's bad for the IETF. For example, take two vendors: Vendor-A and Vendor-B. One of the vendor's has legitimate IPR claims on a PS RFC, the other either has a license on that IPR from the inventing vendor, or has implemented it under the IPR claim's royalty-free IPR statement (just as some IPR has in its claim into the IETF). Some PS RFCs are either very little used or very complicated, meaning they aren't very popular (to the Open Source community) or cost to much (time/money) to develop. So unless someone decides to do the work anyway (which doesn't make sense to require) - the suggested text above prevents both Vendor-A's and Vendor-B's implementations from being considered for elevation of this PS RFC to DS RFC *because* they (for some crazy reason) want to charge money for the products where this implementation can be utilized. BTW - isn't charging money for products how vendor's stay in business? The IETF preventing vendors from making money in order for the IETF to consider progressing a PS RFC to DS RFC is completely counterintuitive and will reduce vendor participation in the IETF. As much as some might applaud that result, it will mean either the demise of the IETF (without sponsors and vendor participants attending meetings to pay the bills), or that everything is just fine as a PS - which makes the suggested text above completely useless. James ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Oppose draft-carpenter-ipr-patent-frswds-00
http://www.ietf.org/internet-drafts/draft-carpenter-ipr-patent-frswds-00.txt offers this text as a modification to RFC 2026: A specification from which at least two independent and interoperable implementations from different code bases have been developed, of which at least one is available as free software, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. I oppose this text in any IETF document because it is counter to vendor implementations (*any* vendor implementations) to achieve Draft Standard status of a document, and that's bad for the IETF. For example, take two vendors: Vendor-A and Vendor-B. One of the vendor's has legitimate IPR claims on a PS RFC, the other either has a license on that IPR from the inventing vendor, or has implemented it under the IPR claim's royalty-free IPR statement (just as some IPR has in its claim into the IETF). Some PS RFCs are either very little used or very complicated, meaning they aren't very popular (to the Open Source community) or cost to much (time/money) to develop. So unless someone decides to do the work anyway (which doesn't make sense to require) - the suggested text above prevents both Vendor-A's and Vendor-B's implementations from being considered for elevation of this PS RFC to DS RFC *because* they (for some crazy reason) want to charge money for the products where this implementation can be utilized. BTW - isn't charging money for products how vendor's stay in business? The IETF preventing vendors from making money in order for the IETF to consider progressing a PS RFC to DS RFC is completely counterintuitive and will reduce vendor participation in the IETF. As much as some might applaud that result, it will mean either the demise of the IETF (without sponsors and vendor participants attending meetings to pay the bills), or that everything is just fine as a PS - which makes the suggested text above completely useless. James ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
