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.
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
_______________________________________________
Ipr-wg mailing list
Ipr-wg@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ipr-wg
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf