Subject: Question about BCP79's Section 4a and its Section 4.1

From: Todd Glassey <[email-masked]>
Date: Sun, 29 Nov 2009 09:39:39 -0800

Folks
in reading section 4a of BCP79 it raises a specific set of questions - 
the first of those being per this section it seems to me that a new IPR 
Header Page needs to be formally added to the RFC template and to the 
I-D template as well; Seriously this clearly says that there will be a 
formal disclosure as part of the RFC (or I-D) that ties that document 
formally to any IPR's filed in that Working Group's Efforts for that 
protocol.

Just read BCP79 itself... its at http://www.ietf.org/rfc/rfc3979.txt

Section 4.a
------------
Actions for Documents for which IPR Disclosure(s) Have Been Received (A) 
When any Intellectual Property Right is disclosed before publication as 
an RFC, with respect to any technology or specification, described in a 
Contribution in the manner set forth in Section 6 of this document, the 
RFC Editor shall ensure that the document include a note indicating the 
existence of such claimed Intellectual Property Rights in any RFC 
published from the Contribution. (See Section 5 below.)
-------------------

So in fact this means any Contribution to the IETF because it does not 
specifically in the term "The Contribution" specify only RFC's as such 
this applies to NoteWell commentary and also to any I-D's submitted 
including any and all email's for any purpose which would form the basis 
of work on that IETF standard.

So any IPR disclosure in any WG Effort would require that the IPR 
disclosure page be created for any and all RFC's published  after BCP79 
went into effect and of course this has not happened. Doesn't that also 
mean that the TRUST has a direct CONSTRUCTIVE RESPONSIBILITY (yes Jorge 
I am using that as a LEGAL TERM OF ART) to also make these same 
functions available for all that IP they have to get releases against so 
that it can be added to the new IETF Trust Process. A task which will 
increase the workload of the Trust significantly.

I bring this up based on a convo which happened in one of the ISC's 
lists about one of the protocols they submit or host for the IETF and 
its membership... But it gets better.

Section 4.1
-----------
Section 4.1 reads: 4.1. No Determination of Reasonable and 
Non-discriminatory Terms: The IESG will not make any explicit 
determination that the assurance of reasonable and non-discriminatory 
terms or any other terms for the use of an Implementing Technology has 
been fulfilled in practice.

-----------
Wow - what a statement, what this means is sweeping in form and shows 
how little insight went into this section. This means simply that the 
IESG and the IETF MAY NOT BLOCK COMMERCIAL STANDARDS from being used. It 
also means that if the IPR of the master implementations is done outside 
the IETF the IETF would accept not having rights to that IP which is 
directly 180 degrees from the original RFC2026 process standard. It also 
creates a Breach of Contract and possibly a Violation of Operating Rules 
claim against the IETF and the other WG members for blocking the 
publication of anything. That would need to formally be communicated to 
the SPONSORS since it clearly hasn't.

As to Section 4.1 - The way its (4.1) is worded now creates a nightmare 
for the IESG and the IETF since it MUST publish everything it receives  
since the IESG is disclosuing responsibility here - the issue is that 
reserving the right to be able to edit content formally creates a 
liability since the IETF (and the IESG) through the RFC-Editor becomes 
the legally-provable source of the genesis on the publication and as 
such this becomes adversarial in form.

Based on the current language, the ONLY way the IESG can claim it is not 
responsible for damages on IPR is to formally publish everything it 
recieves and refusing to do so creates a liability whether the IPR WG 
wants to believe it or not.

Todd Glassey

---

From: Russ Housley <[email-masked]>
Date: Sun, 29 Nov 2009 14:11:09 -0500

I believe that it was argued that IETF-stream RFCs should include a 
pointer to the place where a reader can find any IPR statements that 
have been issued.  That way, the reader can locate the statements, 
even if they are issued well after the RFC is published.

Russ

At 12:39 PM 11/29/2009, Todd Glassey wrote:
>Folks
>in reading section 4a of BCP79 it raises a specific set of questions 
>- the first of those being per this section it seems to me that a 
>new IPR Header Page needs to be formally added to the RFC template 
>and to the I-D template as well; Seriously this clearly says that 
>there will be a formal disclosure as part of the RFC (or I-D) that 
>ties that document formally to any IPR's filed in that Working 
>Group's Efforts for that protocol.
>
>Actions for Documents for which IPR Disclosure(s) Have Been Received 
>(A) When any Intellectual Property Right is disclosed before 
>publication as an RFC, with respect to any technology or 
>specification, described in a Contribution in the manner set forth 
>in Section 6 of this document, the RFC Editor shall ensure that the 
>document include a note indicating the existence of such claimed 
>Intellectual Property Rights in any RFC published from the 
>Contribution. (See Section 5 below.)
>-------------------
>
>So in fact this means any Contribution to the IETF because it does 
>not specifically in the term "The Contribution" specify only RFC's 
>as such this applies to NoteWell commentary and also to any I-D's 
>submitted including any and all email's for any purpose which would 
>form the basis of work on that IETF standard.
>
>disclosure page be created for any and all RFC's published  after 
>BCP79 went into effect and of course this has not happened. Doesn't 
>that also mean that the TRUST has a direct CONSTRUCTIVE 
>RESPONSIBILITY (yes Jorge I am using that as a LEGAL TERM OF ART) to 
>also make these same functions available for all that IP they have 
>to get releases against so that it can be added to the new IETF 
>Trust Process. A task which will increase the workload of the Trust 
>significantly.
>
>lists about one of the protocols they submit or host for the IETF 
>and its membership... But it gets better.
>
>
>Section 4.1
>-----------
>determination that the assurance of reasonable and 
>non-discriminatory terms or any other terms for the use of an 
>Implementing Technology has been fulfilled in practice.
>
>-----------
>Wow - what a statement, what this means is sweeping in form and 
>shows how little insight went into this section. This means simply 
>that the IESG and the IETF MAY NOT BLOCK COMMERCIAL STANDARDS from 
>being used. It also means that if the IPR of the master 
>implementations is done outside the IETF the IETF would accept not 
>having rights to that IP which is directly 180 degrees from the 
>original RFC2026 process standard. It also creates a Breach of 
>Contract and possibly a Violation of Operating Rules claim against 
>the IETF and the other WG members for blocking the publication of 
>anything. That would need to formally be communicated to the 
>SPONSORS since it clearly hasn't.
>
>As to Section 4.1 - The way its (4.1) is worded now creates a 
>nightmare for the IESG and the IETF since it MUST publish everything 
>it receives
>since the IESG is disclosuing responsibility here - the issue is 
>that reserving the right to be able to edit content formally creates 
>a liability since the IETF (and the IESG) through the RFC-Editor 
>becomes the legally-provable source of the genesis on the 
>publication and as such this becomes adversarial in form.
>
>Based on the current language, the ONLY way the IESG can claim it is 
>not responsible for damages on IPR is to formally publish everything 
>it recieves and refusing to do so creates a liability whether the 
>IPR WG wants to believe it or not.
>
>Todd Glassey
>
>
>
>_______________________________________________
>Ipr-wg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ipr-wg

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 29 Nov 2009 12:22:09 -0700

"Todd Glassey" <tglassey at earthlink dot net> wrote:

> the first of those being per this section it seems to me that a new 
> IPR Header Page needs to be formally added to the RFC template and to 
> the I-D template as well;

I read Russ's response about the pointer as a glimmer of hope that there 
will NOT be a whole new page of legalese added to every RFC and I-D. 
For those of us who are not lawyers or corporations specializing in IPR, 
the signal-to-noise ratio here is getting a bit ridiculous.

--
Doug Ewell  |  Thornton, Colorado, USA  |  http://www.ewellic.org
RFC 5645, 4645, UTN #14  |  ietf-languages @ http://is.gd/2kf0s