Subject: Oppose draft-carpenter-ipr-patent-frswds-00

From: "James M. Polk" <[email-masked]>
Date: Mon, 29 Oct 2007 14:20:19 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 29 Oct 2007 15:44:16 -0400

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:

> 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.
>
> 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
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Oct 2007 09:27:09 +1300

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:
>> vendor implementations (*any* vendor implementations) to achieve Draft 
>> Standard status of a document, and that's bad for the IETF.
>>
>> 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.
>>
>> 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
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Oct 2007 09:27:09 +1300

Brian

---

From: "Eric Burger" <[email-masked]>
Date: Mon, 29 Oct 2007 14:23:28 -0700

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-masked]] 
Sent: Monday, October 29, 2007 3:20 PM
To: [email-masked]
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

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.

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.

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

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.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 29 Oct 2007 22:48:56 +0100

> 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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 29 Oct 2007 18:03:22 -0500

>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?

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 30 Oct 2007 10:24:44 +0100

> 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.

> 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.

> intended to kill any IPR from achieving DS. Is that what is intended

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 30 Oct 2007 13:37:23 -0500

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
>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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 30 Oct 2007 13:45:19 -0500

>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?