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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf