Subject: Re: Fwd: DISCUSS: draft-ietf-rmt-bb-fec-ldpc

From: Russ Housley <[email-masked]>
Date: Tue, 27 Nov 2007 17:48:05 -0500

The newest version of the document has resolved this concern.  It now says:

    A publicly available reference implementation of these codes is
    available and distributed under a GNU/LGPL license [LDPC-codec].
    Besides, the code extracts included in this document (except
    Appendix A that is only provided as an example) are directly
    contributed to the IETF process by the authors of this document and
    by Radford M. Neal.

Sorry for the false alarm.

Russ

At 10:05 AM 11/27/2007, Russ Housley wrote:
>Here is an extract from a DISCUSS position that I just posted.  I'd 
>appreciate any advice that this WG may have on an easy way to 
>resolve this situation.
>
>Russ
>
>
>>   There are code extracts in the document, and the Introduction says:
>>   >
>>   > A publicly available reference implementation of these codes is
>>   > available and distributed under a GNU/LGPL license [8].
>>   >
>>   It would be desirable to add an explicit statement that the code
>>   extracts in the document are directly contributed to the IETF process
>>   by their authors (i.e., they are are not subject to LGPL).  To this
>>   end, the authors have proposed:
>>   >
>>   > The code extracts in this document are directly contributed to the
>>   > IETF process by their authors, unless otherwise mentionned.
>>   >
>>   The document authors don't own the copyright of all of the source code,
>>   and therefore cannot contribute it to the IETF process. This is the
>>   case for Pseudo Random Number Generator in Section 5.6 and the Parity
>>   Check Matrix Creation in Section 6.2.  The origin of this source code
>>   is clearly stated.  There has been a huge amount of discussion about
>>   source code in RFCs, and it is not clear that the rights offered are
>>   adequate for a standards track RFC.

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

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 28 Nov 2007 14:56:32 +0100

The code in Appendix A mention another author, Robin Whittle:

   /*
    * Returns a random integer in [0; maxv-1]
    * Derived from rand31pmc, Robin Whittle,
    * September 20th, 2005.
    * http://www.firstpr.com.au/dsp/rand31/
    *      16807           multiplier constant (7^^5)
    *      0x7FFFFFFF      modulo constant (2^^31-1)
    * The inner PRNG produces a value between 1 and
    * 0x7FFFFFFE (2^^31-2) inclusive.
    * This value is then scaled between 0 and maxv-1
    * inclusive.
    */
   unsigned long
   rand (unsigned long maxv)
   {
           unsigned long   hi, lo;

           lo = 16807 * (seed & 0xFFFF);
           hi = 16807 * (seed >> 16);  /* binary shift to right */
           lo += (hi & 0x7FFF) << 16;  /* binary shift to left */
           lo += hi >> 15;
           if (lo > 0x7FFFFFFF)
                   lo -= 0x7FFFFFFF;
           seed = lo;
           /* don't use modulo, least significant bits are less random
            * than most significant bits [PTVF92] */
           return ((unsigned long)
                   ((double)maxv * (double)seed / (double)0x7FFFFFFF));
   }

The text in -07 does not make it clear that the copyright owner of that
code also agreed to contribute it under the IETF license.  Is that the
case?  Whittle is neither the author of the document nor acknowledged in
the new text in -07.

The code linked from the URL is interesting:

http://www.firstpr.com.au/dsp/rand31/rand31-park-miller-carta.cc.txt
// rand31pmc
//
// Robin Whittle  2005 September 20
//
// 31 bit pseudo-random number generator based on:
//
//   Lehmer (1951)
//   Lewis, Goodman & Miller (1969)
//   Park & Miller (1983)
//   
// implemented according to the optimisation suggested by David G. Carta
// in 1990 which uses 32 bit math and does not require division.  
// Park and Miller rejected Carta's approach in 1993.  Carta provided no 
// code examples.  Carta's approach produces identical results to Park 
// and Miller's code.
//
// Copyright public domain . . . *but*:
//
// * Please leave the comments intact so inquiring minds have a chance of 
// * understanding how this implementation works and chasing the 
// * references to see the strengths and limitations of this particular 
// * pseudo-random number generator.

/Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Nov 2007 07:44:54 +1300

"  Besides, the code extracts included in this document (except
    Appendix A that is only provided as an example) are directly
    contributed to the IETF process by the authors of this document and
    by Radford M. Neal."

so Appendix A is explicitly not covered by the contribution
rules.

This is special-casing under today's rules. It might be worth using
this draft as a test case for the -incoming draft.

     Brian

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 28 Nov 2007 11:36:35 -0800

Brian
----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>
Cc: "IPR WG" <[email-masked]>
Sent: Wednesday, November 28, 2007 10:44 AM
Subject: Re: Fwd: DISCUSS: draft-ietf-rmt-bb-fec-ldpc

> this draft as a test case for the -incoming draft.

The problem you run into here is that by publishing IP that the rights to 
are excepted from this Standard means that the IETF is then creating a 
proprietary IP as work-product in the publishing of those IP's which will 
retain rights to parts of the standard and any derivatives based therein. 
Isnt this exactly what the intent of the making-everything-opensourced was 
supposed to stop???

I am not objecting to the realization you made here Brian, just to the 
inconsistency here with regard to what rights are included. The real issue 
is that by publishing IP that the Relying Party WILL NOT HAVE RIGHTS TO 
"contaminates the ownership of Derivatives" since a license to produce those 
WILL NOT PROVIDE for those needs. As such ANY documents published with IP 
that the IETF  doesnt hold rights to under the current "End User Rights" 
model are affected by this.

Todd

>> //   // implemented according to the optimisation suggested by David G. 
>> Carta
>> // in 1990 which uses 32 bit math and does not require division.  // Park 
>> and Miller rejected Carta's approach in 1993.  Carta provided no // code 
>> examples.  Carta's approach produces identical results to Park // and 
>> Miller's code.
>> //
>> // * understanding how this implementation works and chasing the // * 
>> references to see the strengths and limitations of this particular // * 
>> pseudo-random number generator.
>>
>> /Simon
>>

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 28 Nov 2007 13:35:49 -0800

This statement while possibly interpreted as being OFFTOPIC is in fact 
dead-on since it pertains to changes that need to be resolved to both 78 and 
79 IP management controls provided to the Relying Parties from the IETF's 
Licensing Model. It also effects the content of any and all submissions to 
the IETF so it is relevant. Its also going to blow some minds in that I am 
about to lay out the statement that under the current model and these new 
rules that there cannot be any proper transfer or derivative rights in this 
situation.

--------

One thing we need to do is better document who is actually represented and 
what their factual contributions are to the Standards IP Development effort. 
The reason is that this directly effects the end rights that are promulgated 
through the SDO Workflow Process.

To understand the IP Ownership issues we collectively as a group have to 
address:

    1)    that IP flowing through the IETF's Work Flow (WF) has several 
states.

    a)    The first one is "The Initial Submission IP" to which the 
individual or entity submitting that IP - that is the "Organic IP" from 
which any IETF initiative is initially codified and initiated. The 
assumption is that the Submitter owns all of the rights therein. They 
probably in fact belong to the Sponsoring Entity(ies) under the Work For 
Hire as the Sponsor one would think.  This is what the Submitter's convey IP 
rights to the IETF for.

    b)    The second state is the IPO (the Initial IETF Published Offering) 
which proposes the question "Comment on Me please" to the Audience. This is 
the first Derivative Work and its created by the Editor's Desk. This is the 
IETF's 100%.

    c)    The third state is the Vetted and Revised or Final (LC Approved) 
Derivative IP which is a collaborative effort by the Vetting Team and those 
who provided the analysis of the "Candidate Technologies". It is 
theoretically owned by all those who participated in the process (right?)... 
OH, and lets not forget that its NOTEWELL that is supposed to protect and 
constrain who owns what here in this derivative.

    2)   There is another concern wherein Submitter's of IP to the IETF 
reference IP that belongs to another individual, entity or is controlled 
under a use licensing model that is not conducive to the IETF's Any and All 
Republishing Use Licensing Model.

The problem I see with this as a Layman is that if the submitter references 
IP THEY DO NOT OWN, then any and all derivative works would be bound by 
those other IP Licenses as well, making the clear title to any and all 
derivative works tied to that original work. Here is the theory - Party "A" 
produces Technology "YAYA" which Party B, who is for instance an Academic, 
and who writes an analysis and technical description of which is then 
submitted in IETF Submission Format for publication to the IETF. The first 
and critical question to answer here is "Does Party B have the legal 
authority here to convey any rights to the IETF for this work other than the 
rights to their own words in the submission?" I think the answer is pretty 
clearly NO...  If not, this submission is then just "a story about 
technology" and not the technology itself and NO derivative technology 
rights are clean here. This ripples throughout the entire process of 
participating in the IETF since it creates notification responsibilities for 
the Sponsoree in the IETF.

The problem is that if the Sponsoree fails to properly keep their Sponsor's 
informed, then the Sponsoree's authority to represent the Sponsor would be 
seriously in question by anyone who has a brain IMHO...

    2)    With regard to the 1C Derivative Works - the Sponsoring Parties 
own the work products of those who they sponsor unless those IP owners also 
formally and in a provable manner, transfer that ownership to the IETF or 
the ISOC's SDO-Trust which is what the Trust actually is per se one would 
think.

    a) The problem the IETF faces is that after the ruling about the 
admissibility of email as binding from Lorraine v. Markel, I think the IETF 
is in trouble there and the Email Submission and Ownership Conveyance model 
is formally broken here whether anyone outside the US likes it or not. 
Sorry...  if you want to fix this get the UN to take over the IETF's 
operations so it will be exempt from National Law, since if it is operated 
here the US Law's pertain and if its operated in the EU the Data Privacy and 
Records Maintenance requirements will choke the Mailing List operators IMHO.

    3)    Since Sponsoring Entity's own their Sponsoree's Work Product, then 
any and all NOTEWELL inclusions are also constrained at least under this and 
may have additional rights that the submitter would then own as well one 
would think. That means that by sponsoring an individuals work in a IETF WG, 
and having that WG produce a proprietary-only standard under the guise of an 
open-effort, would constitute an instance where the other sponsor's would be 
footing the bills for their engineer's to work on the other IP Owner's 
properties and this isn't going to sit well with people IMHO.

    4)    Since ne noted that others than the IETF itself can retain working 
rights under the proposed model, WG's rely on NOTEWELL through their Vetting 
Process, that IP exchanged and developed by the Sponsoree's in their 
interaction with the WG is yet another derivative IP product.

So... what this all boils down to is that I don't think the IETF can accept 
any IP submissions with third-party rights of any type attached to them, 
which the IETF cannot directly document are 'reliably transferable' through 
the IETF's processes meaning that this document among others is broken...

Todd Glassey

----- Original Message ----- 
From: "TS Glassey" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>; "Simon Josefsson" 
<[email-masked]>
Cc: "IPR WG" <[email-masked]>
Sent: Wednesday, November 28, 2007 11:36 AM
Subject: Re: Fwd: DISCUSS: draft-ietf-rmt-bb-fec-ldpc

> "contaminates the ownership of Derivatives" since a license to produce 
> those WILL NOT PROVIDE for those needs. As such ANY documents published 
> with IP that the IETF  doesnt hold rights to under the current "End User 
> Rights" model are affected by this.
>
> Todd
>
>>
>>     Brian
>>
>>> // in 1990 which uses 32 bit math and does not require division.  // 
>>> Park and Miller rejected Carta's approach in 1993.  Carta provided no // 
>>> code examples.  Carta's approach produces identical results to Park // 
>>> and Miller's code.
>>> //
>>> // * Please leave the comments intact so inquiring minds have a chance 
>>> of // * understanding how this implementation works and chasing the // *

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 28 Nov 2007 23:29:07 +0100

> so Appendix A is explicitly not covered by the contribution

How can Appendix A be included in the draft?  It seems that it wasn't
written by the document authors nor Mr. Neal.  BCP 78 says the necessary
rights to text need to be granted to the IETF.

/Simon

>> //   // implemented according to the optimisation suggested by David
>> G. Carta
>> Park and Miller rejected Carta's approach in 1993.  Carta provided
>> no // code examples.  Carta's approach produces identical results to
>> Park // and Miller's code.
>> //
>> // * Please leave the comments intact so inquiring minds have a
>> chance of // * understanding how this implementation works and
>> chasing the // * references to see the strengths and limitations of
>> this particular // * pseudo-random number generator.
>>
>> /Simon
>>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Nov 2007 11:45:11 +1300

> rights to text need to be granted to the IETF.

For normative material, sure. We've always been flexible and pragmatic for
non-normative material though.

    Brian

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 28 Nov 2007 14:57:01 -0800

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>
Cc: "IPR WG" <[email-masked]>
Sent: Wednesday, November 28, 2007 2:45 PM
Subject: Re: Fwd: DISCUSS: draft-ietf-rmt-bb-fec-ldpc

> non-normative material though.

How do you document that there isnt any genesis or cross contamination of 
the protected IP into the Standards Process itself ? Doest this taint the 
Standard...

---

From: [email-masked]
Date: Wed, 28 Nov 2007 18:39:58 -0500

Someone (Jorge?) should double-check that -incoming
is consistent with the operation of the "work for hire"
principle of copyright law, which essentially assigns
copyright in anything created by an employee as part
of his/her job responsibilities to his/her employer.

This is mentioned in Section 2 and there is enough
usage of "sponsored by", "organization the Contributor
represents" and the like in Section 5 to indicate
that "work for hire" has been considered and -incoming
is probably ok, but an opinion from an actual lawyer
would be helpful.

There may be a need for the submission tool to give
enough notice of "work for hire" in plain language
(i.e., not legalese) to a submitter in order to ensure
that section 5.6.c of -incoming applies to someone who
doesn't have their employer's permission to submit,
but submits anyway.

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: Simon Josefsson <[email-masked]>
Date: Thu, 29 Nov 2007 10:45:01 +0100

> non-normative material though.

That is news to me.  The base64 code was very clearly only intended to
be informative in all drafts of RFC 4648.

To get this straight, are you saying that the IETF legal policies only
apply to the normative parts of IETF documents?

I cannot find anything in BCP 78 or -incoming or -outgoing to
substantiate such a claim.  Grepping for 'normativ' doesn't lead to
anything as far as I can tell.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 29 Nov 2007 11:31:02 +0100

> apply to the normative parts of IETF documents?
I think that's an insupportable argument. Stuff in IETF documents is 
stuff in IETF documents.

So I disagree (strongly) with Brian here.

Note: We all know that things that have been done in the past are 
inconsistent with each other, and inconsistent with our new (and 
hopefully clearer) processes. So arguing from past cases is interesting, 
but can't be the deciding argument.

            Harald

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Nov 2007 11:14:25 +1300

> I think that's an insupportable argument. Stuff in IETF documents is 

I agree with that. I said something very different: *in practice*
we've been flexible and pragmatic when it comes to non-normative text.
That doesn't mean that this WG shouldn't try to make the future BCPs
deal correctly with such cases, but this is a draft being processed
under the existing BCPs.

As it happens, the authors and Robin Whittle have come up with
an agreed solution, but that isn't this WG's business IMHO,
except as an example of gaps in the existing BCPs.

> but can't be the deciding argument.

I agree.

     Brian

---

From: "todd glassey" <[email-masked]>
Date: Thu, 29 Nov 2007 14:34:34 -0800

The question Harald that NO ONE seems to want answered is what expectations 
of continued support these new rules imply on previous initiatives, like for 
instance, if one of the older initiatives gets a new I-D filed against that 
core technology for instance does that get filed under the current or 
previous rules? - it makes a difference, since changing the playing field on 
initiatives which are in progress is  probably not going to work since it 
would create different rules for controlling the various IP's in that 
Standards Initiative package (* i.e. being something like the sum of all 
NOTEWELL and IETF Documents in a standards process).

The issue is that the IETF has existing agreements with all of the 
previously filed documents and as such it cannot magically just say "Hey all 
IETF published documents are now under these rules..." unless you want to 
wind up in court that is...

Todd Glassey

----- Original Message ----- 
From: "Harald Alvestrand" <[email-masked]>
To: "Simon Josefsson" <[email-masked]>
Cc: "Brian E Carpenter" <[email-masked]>; "IPR WG" 
<[email-masked]>
Sent: Thursday, November 29, 2007 2:31 AM
Subject: Re: Fwd: DISCUSS: draft-ietf-rmt-bb-fec-ldpc

> I think that's an insupportable argument. Stuff in IETF documents is stuff 
> in IETF documents.
>
> inconsistent with each other, and inconsistent with our new (and hopefully 
> clearer) processes. So arguing from past cases is interesting, but can't 
> be the deciding argument.
>
>            Harald
>

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 30 Nov 2007 14:52:22 +0100

> we've been flexible and pragmatic when it comes to non-normative text.

Given the context of this particular draft, and the question of what
advice the WG should give about it, any earlier arguable incorrect
practices seems irrelevant.

> except as an example of gaps in the existing BCPs.

Yes, and as far as I understand, the authors reached the logical
conclusion of replacing the code with a reference to the web site.  This
was what happened for the Base64 draft as well.

I think this outcome is unfortunate, it would be better if code can be
included in the archival document.  External web pages come and go, and
you never know exactly what has changed since the document was
published.  I think the IPR WG should address this.

/Simon

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 30 Nov 2007 15:46:14 +0100

> published.  I think the IPR WG should address this.
I think the WG has addressed this.

I think the WG has concluded that it's unacceptable to publish source 
code in an RFC that, if copied from the RFC and modified by a reader, 
would place a GPL (or any other copyright-based) requirement on that reader.

And I think that's a sensible conclusion to come to.

                 Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 30 Nov 2007 17:49:27 +0100

(Responding because it's Friday.)

TS Glassey wrote:
> dead-on since it pertains to changes that need to be resolved to both 
> 78 and 79 IP management controls provided to the Relying Parties from 
> the IETF's Licensing Model. It also effects the content of any and all 
> submissions to the IETF so it is relevant. Its also going to blow some 
> minds in that I am about to lay out the statement that under the 
> current model and these new rules that there cannot be any proper 
> transfer or derivative rights in this situation.
It's an offtopic contribution, because the IETF has not accepted your 
model of the world. You have advanced it multiple times, and at no time 
has any other party indicated that this model is valid.

Furthermore, the WG is not presently chartered to deal with the issue of 
patents. It deals with copyright issues. I comment on the below based on 
the theory that you are talking about copyright issues, and licenses 
based on copyrights.
>
> --------
>
> One thing we need to do is better document who is actually represented 
> and what their factual contributions are to the Standards IP 
> Development effort. The reason is that this directly effects the end 
> rights that are promulgated through the SDO Workflow Process.
>
> To understand the IP Ownership issues we collectively as a group have 
> to address:
>
Yes - the IPR that is the license based on copyright has two states: Not 
submitted and submitted.
> individual or entity submitting that IP - that is the "Organic IP" 
> from which any IETF initiative is initially codified and initiated. 
> The assumption is that the Submitter owns all of the rights therein. 
> They probably in fact belong to the Sponsoring Entity(ies) under the 
> Work For Hire as the Sponsor one would think.  This is what the 
> Submitter's convey IP rights to the IETF for.
The current documents do not make a special case for "initial submission".
>
>    b)    The second state is the IPO (the Initial IETF Published 
> Offering) which proposes the question "Comment on Me please" to the 
> Audience. This is the first Derivative Work and its created by the 
> Editor's Desk. This is the IETF's 100%.
There is no element of the IETF's process that has these properties.
>
>    c)    The third state is the Vetted and Revised or Final (LC 
> Approved) Derivative IP which is a collaborative effort by the Vetting 
> Team and those who provided the analysis of the "Candidate 
> Technologies". It is theoretically owned by all those who participated 
> in the process (right?)... OH, and lets not forget that its NOTEWELL 
> that is supposed to protect and constrain who owns what here in this 
> derivative.
The IETF does not use the term "vetting", so the statement above is 
meaningless in the IETF context.
> reference IP that belongs to another individual, entity or is 
> controlled under a use licensing model that is not conducive to the 
> IETF's Any and All Republishing Use Licensing Model.
>
> The problem I see with this as a Layman is that if the submitter 
> references IP THEY DO NOT OWN, then any and all derivative works would 
> be bound by those other IP Licenses as well, making the clear title to 
> any and all derivative works tied to that original work. Here is the 
> theory - Party "A" produces Technology "YAYA" which Party B, who is 
> for instance an Academic, and who writes an analysis and technical 
> description of which is then submitted in IETF Submission Format for 
> publication to the IETF. The first and critical question to answer 
> here is "Does Party B have the legal authority here to convey any 
> rights to the IETF for this work other than the rights to their own 
> words in the submission?" I think the answer is pretty clearly NO...  
> If not, this submission is then just "a story about technology" and 
> not the technology itself and NO derivative technology rights are 
> clean here. This ripples throughout the entire process of 
> participating in the IETF since it creates notification 
> responsibilities for the Sponsoree in the IETF.
The submitter claims to have the right to submit the contribution to the 
IETF. It is a core part of the IETF's procedures that we believe the 
submitter. So the problem you state is a problem about what happens if 
the IETF gets lied to. That has not been a practical problem so far.
>
> The problem is that if the Sponsoree fails to properly keep their 
> Sponsor's informed, then the Sponsoree's authority to represent the 
> Sponsor would be seriously in question by anyone who has a brain IMHO...
>
>    2)    With regard to the 1C Derivative Works - the Sponsoring 
> Parties own the work products of those who they sponsor unless those 
> IP owners also formally and in a provable manner, transfer that 
> ownership to the IETF or the ISOC's SDO-Trust which is what the Trust 
> actually is per se one would think.
No need for wet signatures or other formal conveyance of the license to 
the IETF has been identified by legal counsel.
> admissibility of email as binding from Lorraine v. Markel, I think the 
> IETF is in trouble there and the Email Submission and Ownership 
> Conveyance model is formally broken here whether anyone outside the US 
> likes it or not. Sorry...  if you want to fix this get the UN to take 
> over the IETF's operations so it will be exempt from National Law, 
> since if it is operated here the US Law's pertain and if its operated 
> in the EU the Data Privacy and Records Maintenance requirements will 
> choke the Mailing List operators IMHO.
According to legal counsel, the Lorraine v. Markel case is not likely to 
be relevant to the IETF's procedures. It's relevant to admissibility of 
evidence in a court of law.
>
>    3)    Since Sponsoring Entity's own their Sponsoree's Work Product, 
> then any and all NOTEWELL inclusions are also constrained at least 
> under this and may have additional rights that the submitter would 
> then own as well one would think. That means that by sponsoring an 
> individuals work in a IETF WG, and having that WG produce a 
> proprietary-only standard under the guise of an open-effort, would 
> constitute an instance where the other sponsor's would be footing the 
> bills for their engineer's to work on the other IP Owner's properties 
> and this isn't going to sit well with people IMHO.
>
>    4)    Since ne noted that others than the IETF itself can retain 
> working rights under the proposed model, WG's rely on NOTEWELL through 
> their Vetting Process, that IP exchanged and developed by the 
> Sponsoree's in their interaction with the WG is yet another derivative 
> IP product.
>
> So... what this all boils down to is that I don't think the IETF can 
> accept any IP submissions with third-party rights of any type attached 
> to them, which the IETF cannot directly document are 'reliably 
> transferable' through the IETF's processes meaning that this document 
> among others is broken...
>
> Todd Glassey
Since you refuse to accept the IETF's self-description of what the 
IETF's process is, and refuse to use the terminology that the IETF uses 
to describe its process, your conclusion is not relevant to the work of 
this working group.

Your posting is offtopic.

               Harald

---

From: "todd glassey" <[email-masked]>
Date: Fri, 30 Nov 2007 10:32:42 -0800

Harald -
I will respond to this formally tonight when I get home...

Todd Glassey

----- Original Message ----- 
From: "Harald Alvestrand" <[email-masked]>
To: "TS Glassey" <[email-masked]>
Cc: "IPR WG" <[email-masked]>
Sent: Friday, November 30, 2007 8:49 AM
Subject: Re: Understanding IP Rights contributions in a SDO... DISCUSS: 
draft-ietf-rmt-bb-fec-ldpc

>> dead-on since it pertains to changes that need to be resolved to both 78 
>> and 79 IP management controls provided to the Relying Parties from the 
>> IETF's Licensing Model. It also effects the content of any and all 
>> minds in that I am about to lay out the statement that under the current 
>> model and these new rules that there cannot be any proper transfer or 
>> derivative rights in this situation.
> the theory that you are talking about copyright issues, and licenses based 
> on copyrights.
>>
>> --------
>>
>> and what their factual contributions are to the Standards IP Development 
>> effort. The reason is that this directly effects the end rights that are 
>> promulgated through the SDO Workflow Process.
>>
>> Hire as the Sponsor one would think.  This is what the Submitter's convey 
>> IP rights to the IETF for.
>> Derivative IP which is a collaborative effort by the Vetting Team and 
>> those who provided the analysis of the "Candidate Technologies". It is 
>> theoretically owned by all those who participated in the process 
>> (right?)... OH, and lets not forget that its NOTEWELL that is supposed to 
>> protect and constrain who owns what here in this derivative.
>> under a use licensing model that is not conducive to the IETF's Any and 
>> All Republishing Use Licensing Model.
>>
>> references IP THEY DO NOT OWN, then any and all derivative works would be 
>> bound by those other IP Licenses as well, making the clear title to any 
>> and all derivative works tied to that original work. Here is the theory - 
>> Party "A" produces Technology "YAYA" which Party B, who is for instance 
>> an Academic, and who writes an analysis and technical description of 
>> which is then submitted in IETF Submission Format for publication to the 
>> IETF. The first and critical question to answer here is "Does Party B 
>> have the legal authority here to convey any rights to the IETF for this 
>> work other than the rights to their own words in the submission?" I think 
>> the answer is pretty clearly NO...  If not, this submission is then just 
>> "a story about technology" and not the technology itself and NO 
>> derivative technology rights are clean here. This ripples throughout the 
>> entire process of participating in the IETF since it creates notification 
> submitter. So the problem you state is a problem about what happens if the 
> IETF gets lied to. That has not been a practical problem so far.
>>
>> own the work products of those who they sponsor unless those IP owners 
>> also formally and in a provable manner, transfer that ownership to the 
>> IETF or the ISOC's SDO-Trust which is what the Trust actually is per se 
>> one would think.
>> over the IETF's operations so it will be exempt from National Law, since 
>> if it is operated here the US Law's pertain and if its operated in the EU 
>> the Data Privacy and Records Maintenance requirements will choke the 
>> Mailing List operators IMHO.
>> then any and all NOTEWELL inclusions are also constrained at least under 
>> this and may have additional rights that the submitter would then own as 
>> well one would think. That means that by sponsoring an individuals work 
>> in a IETF WG, and having that WG produce a proprietary-only standard 
>> under the guise of an open-effort, would constitute an instance where the 
>> other sponsor's would be footing the bills for their engineer's to work 
>> on the other IP Owner's properties and this isn't going to sit well with 
>> people IMHO.
>>
>> their Vetting Process, that IP exchanged and developed by the Sponsoree's 
>> in their interaction with the WG is yet another derivative IP product.
>>
>> accept any IP submissions with third-party rights of any type attached to 
>> them, which the IETF cannot directly document are 'reliably transferable' 
>> through the IETF's processes meaning that this document among others is 
>> broken...
>>
>> Todd Glassey
> Since you refuse to accept the IETF's self-description of what the IETF's 
> process is, and refuse to use the terminology that the IETF uses to 
> describe its process, your conclusion is not relevant to the work of this 
> working group.
>