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:jmpolk@xxxxxxxxx] Sent: Monday, October 29, 2007 3:20 PM To: ietf@xxxxxxxx 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@xxxxxxxx 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf