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(_at_)cisco(_dot_)com]
Sent: Monday, October 29, 2007 3:20 PM
To: ietf(_at_)ietf(_dot_)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(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf