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

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

I will continue to divert discussion to the ipr list each time
I remember...

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

Indeed. But the only place in our process where we actually
evaluate implementations is there (and at the DS->STD stage).
Where else can we apply an empirical test?

     Brian

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 30 Oct 2007 09:25:54 +0100

James M. Polk wrote:

> but why does one or both have to be open source?

Because it's a "standard", everybody should be free
to implement it.  Confusing "product" and "standard"
doesn't help.

> Why can't both be commercial?

Nothing's wrong with "products", we buy and use them
all the time.  But of course I'm less interested to
promote or develop "products" without a salary.

The "standards process" is about making the Internet
better, selling "products" is a completely different
task.
 
| 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.

Then they don't qualify as DS.  Why should (unpaid) 
volunteers bother to check the interoperability of 
commercial products and stamp them as DS ?

 Frank

---

From: [email-masked]
Date: Tue, 30 Oct 2007 09:39:17 -0400

Frank, 

> commercial products and stamp them as DS ?

I have to object to the implicit assumption that the
community of "(unpaid) volunteers" working on free (or
open source or whatever term you prefer) software is
entitled to a veto over what protocols are useful enough
to be promoted to draft standard.  I would similarly
object to giving the corresponding community of
commercial (or for profit or whatever term you prefer)
software developers the same sort of veto.  Both
communities should be valid sources of implementations
that fulfill the interoperability requirements of
DS, but requiring at least one from each community
confers unwarranted and unwise veto power, IMHO.

In what we do here, we need to remember that the Internet
is for everyone, and we need to do our best to span
these communities (and in fact all communities of
implementers) so that IETF protocols enjoy the widest
possible support.  IMHO, having any one community
dictate terms to the other(s) is not a useful means
of achieving that goal.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 31 Oct 2007 10:00:24 +1300

On 2007-10-31 08:24, James M. Polk wrote:
> At 09:56 PM 10/29/2007, Brian E Carpenter wrote:
> Why does an empirical test require an open source (of the two required)?

It doesn't. That would be a definite change to the present rules.
I think this discussion is testing whether there's any support for
such a change.

> 
> Why can't Cisco and IBM get together and work out (and prove) completely 
> compliant implementations of an RFC?
> 
> I guess I'm reading your text as a MUST, when I'm not so opposed to a 
> SHOULD strength, with the reason not to do it as a given protocol is too 
> complicated or very limited in popularity for anyone to reasonably do 
> everything (open source) within in the next n (5?) years.  The IESG can 
> judge that one, based on two commercial implementations being presented 
> to them with the intention of progressing a PS to a DS.

If the consensus here is for a SHOULD level, I'll be happy to update
my draft accordingly. (In fact, I believe a SHOULD level doesn't require
a formal update to RFC 2026 - it could simply become part of the IESG's
current practice.)

> 
> BTW - I'm a believer that all WGs have a charter item to move their core 
> protocol to DS. 

Factually, they don't. But that isn't an IPR WG issue...

> Yet if a mandate were to be "one has to be open source", 
> this DS charter item idea is pointless, because WG chairs shouldn't be 
> in a position to dictate there become a completely compliant open source 
> implementation. This becomes a popularity contest of making protocols 
> simpler (re: less features), to the point of that protocol possibly not 
> addressing the requirements for a solution.

Actually that is a general problem of trying to avoid patents - you
have to remove pretty much all innovative ideas.

> Let's use something like RSVP as an example protocol, requiring an open 
> source implementation before any commercial implementations are 
> compliant with RFC 2205.

Where does the "before" come from?

> I say "fat chance that will happen", leaving 
> RSVP - which has been implemented and operational for almost 10 years 
> now on virtually _every_ Cisco router - to live at PS forever...

I'm not familiar with RSVP software, but routing software is an area
where your argument is strongest. For host software I think we
often see open source code appearing first.

     Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 30 Oct 2007 10:11:40 -0400

I'd like to achieve equivalent  maturity for promotion on the  
technical and IPR side.

Roughly speaking, on the technical side, we have two hurdles:

(1) PS must be specified well enough to be implementable and to be  
evaluated without implementation by third parties for suitability, at  
the time the document is published

(2) DS candidates must have shown multiple implementation

By analogy, PS should specify licensing at sufficient precision to  
allow to evaluate. We would never allow "please use reasonable  
security and fair transport" for a PS, as it simply lacks sufficient  
detail to be usefully evaluated. The same should be true for licensing.

Also, in practice, we now require or strongly encourage  
implementation before something reaches PS. We should do the same  
thing for IPR licensing.

Also, if the authors or (maybe) working group chairs are also IPR  
filers, they should be held to a higher standard. For example, they'd  
have to make licensing available before PS, so that the design is  
testable before it's last-called. I'd rather find out about problems  
early, even if I can't find out about all possible problems.

I also see no problem with a working group making an early  
implementation (of technology and licensing) a condition for WGLC. We  
do this today for more risky or complex PS candidates, but only on  
the technology side.

As on the technical side, we should try to address the "known  
unknowns" and realistically can't anticipate all deployment issues.  
Just because we can't anticipate all non-IETF-participant IPR issues  
is no good reason not to address the ones we do know about.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 30 Oct 2007 21:31:06 -0400

Huh? There are at least two open-source implementations for RSVP (ISI  
and KOM) that I know of, and that's probably a small subset.

For DS, the chairs and the WG determine lots of criteria for  
advancement, in particular, how diligent the interoperability tests  
need to be, what documentation needs to be provided, what features  
need to be ditched (it seems very rare that every single parameter or  
corner case in a protocol has two implementations or is truly  
tested), etc. Allowing a WG to raise the bar for an important  
protocol likely to see open-source implementations seems like a  
reasonable degree of freedom.

> Let's use something like RSVP as an example protocol, requiring an  
> open source implementation before any commercial implementations  
> are compliant with RFC 2205.  I say "fat chance that will happen",  
> leaving RSVP - which has been implemented and operational for  
> almost 10 years now on virtually _every_ Cisco router - to live at  
> PS forever...
>
>
>>     Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 30 Oct 2007 21:38:04 -0400

As far as I know, there is no requirement that there are two  
implementations that implement all features and interoperate. It is  
sufficient that for every feature, that there's a pair of  
implementations. This was certainly the case when RTP made it to DS,  
as the likelihood of having two complete implementations e.g., of RFC  
3551 (RTP profile), is rather low.

In analogy, this means that an open-source implementation doesn't  
have to be feature-complete to "count". It just has to exercise the  
licensing protocol and interoperate on whatever subset of spec  
features it has.

Thus, I'm afraid you're building a strawman.

Henning

On Oct 30, 2007, at 5:42 PM, James M. Polk wrote:

> At 04:00 PM 10/30/2007, Brian E Carpenter wrote:
>>> Let's use something like RSVP as an example protocol, requiring  
>>> an open source implementation before any commercial  
>>> implementations are compliant with RFC 2205.
>>
> fair nit. I shouldn't have used "before".
>
> That said, if it isn't in parallel with commercial developments,  
> then the commercial developers doing the hard work to promote a  
> protocol (such as RSVP or even SIP) to DS will get frustrated if  
> they have to wait, perhaps years (if ever), for someone to  
> _complete_ (key word there) an open source version, and not stop  
> with a partial solution they feel is good enough for their own  
> requirement(s).
>
> I argue this is a fairly large disincentive for any commercial  
> effort to work towards DS promotion of any protocol.  I hope that  
> isn't a goal, and don't believe it is, but it might be a consequence.
>
> James
>

---

From: "todd glassey" <[email-masked]>
Date: Wed, 31 Oct 2007 10:24:04 -0700

----- Original Message ----- 
From: "Henning Schulzrinne" <[email-masked]>
To: "James M. Polk" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; "IPR WG" 
<[email-masked]>
Sent: Tuesday, October 30, 2007 6:38 PM
Subject: Re: Oppose draft-carpenter-ipr-patent-frswds-00

> implementations that implement all features and interoperate.

This is because there is nofunctional test/qualification plan as part of the 
actual requirements are. Its one of the things that makes this standards 
process iffy. We need to have a formal "Qualifications Process" document 
which mechanically enumerates the Testing/Qualification Process that the 
IETF relies on, and this is way more important that most probably think... 
it is a key aspect of the IETF's getting more credibility becuase when the 
IESG tells people they voted on whether something is ready for advancement 
those members of the IESG clearly open themselves, the IETF/IESG, and their 
sponsors to litigation based on damages or hurdles that are artificially 
erected as personal agendas of those people in control of those 
organizations within this SDO...

Sorta like what was done to me by Harald and the other members of the 
[email-masked] WG in that bogus PR Action against my posting rights...

Todd Glassey

> It is  sufficient that for every feature, that there's a pair of 
> implementations. This was certainly the case when RTP made it to DS,  as 
> the likelihood of having two complete implementations e.g., of RFC  3551 
> (RTP profile), is rather low.
>
> In analogy, this means that an open-source implementation doesn't  have to 
> be feature-complete to "count". It just has to exercise the  licensing 
> protocol and interoperate on whatever subset of spec  features it has.
>
>>>> open source implementation before any commercial  implementations are 
>>>> compliant with RFC 2205.
>>>
>> That said, if it isn't in parallel with commercial developments,  then 
>> the commercial developers doing the hard work to promote a  protocol 
>> (such as RSVP or even SIP) to DS will get frustrated if  they have to 
>> wait, perhaps years (if ever), for someone to  _complete_ (key word 
>> there) an open source version, and not stop  with a partial solution they 
>> feel is good enough for their own  requirement(s).
>>
>> I argue this is a fairly large disincentive for any commercial  effort to 
>> work towards DS promotion of any protocol.  I hope that  isn't a goal, 
>> and don't believe it is, but it might be a consequence.
>>
>> James
>>
>
>

---

From: "todd glassey" <[email-masked]>
Date: Wed, 31 Oct 2007 10:36:50 -0700

The point of this commentary is to create an IETF that is truly open and 
fair for all and who's processes are not voted on for each new effort that 
comes through. That is a recipe for fraud IMHO. So in properly defining how 
Proposed Standards are formally validated and the environment from which 
that validation happens is key going forward I think.

Todd
----- Original Message ----- 
From: "todd glassey" <[email-masked]>
To: "Henning Schulzrinne" <[email-masked]>; "James M. Polk" 
<[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; "IPR WG" 
<[email-masked]>
Sent: Wednesday, October 31, 2007 10:24 AM
Subject: Re: Oppose draft-carpenter-ipr-patent-frswds-00

> This is because there is nofunctional test/qualification plan as part of 
> the actual requirements are. Its one of the things that makes this 
> standards process iffy. We need to have a formal "Qualifications Process" 
> document which mechanically enumerates the Testing/Qualification Process 
> that the IETF relies on, and this is way more important that most probably 
> think... it is a key aspect of the IETF's getting more credibility becuase 
> when the IESG tells people they voted on whether something is ready for 
> advancement those members of the IESG clearly open themselves, the 
> IETF/IESG, and their sponsors to litigation based on damages or hurdles 
> that are artificially erected as personal agendas of those people in 
> control of those organizations within this SDO...
>
>> In analogy, this means that an open-source implementation doesn't  have 
>> to be feature-complete to "count". It just has to exercise the  licensing 
>>> there) an open source version, and not stop  with a partial solution 
>>> they feel is good enough for their own  requirement(s).
>>>
>>> I argue this is a fairly large disincentive for any commercial  effort 
>>> to work towards DS promotion of any protocol.  I hope that  isn't a 
>>> goal, and don't believe it is, but it might be a consequence.
>>>
>>> James
>>>
>>
>>