Thanks for incorporating my requests from -08, many even using exactly
the text I suggested. Much appreciated. A few comments on those changes,
and a few comments on some of the other changes that were made since
last I reviewed.
On 18 Jan 2017, at 8:52, Jari Arkko wrote:
* Pete Resnick suggested to put back in the three principles to
Section 2 that were deleted from the previous RFC (April 11).
We’ve done so; we should only make substantive changes
to the original RFC when there’s clear consensus to do so.
I can't find these in -10. I suggested that they go in at the second
paragraph of section 2:
OLD
Section 1 defines...
NEW
RFC 2026, Section 10 established three basic principles regarding
the IETF dealing with claims of Intellectual Property Rights:
(a) the IETF will make no determination about the validity of any
particular IPR claim
(b) the IETF following normal processes can decide to use
technology
for which IPR disclosures have been made if it decides that
such
a use is warranted
(c) in order for the working group and the rest of the IETF to have
the information needed to make an informed decision about the
use of a particular technology, all those contributing to the
working group's discussions must disclose the existence of any
IPR the Contributor or other IETF participant believes Covers
or
may ultimately Cover the technology under discussion. This
applies to both Contributors and other participants, and
applies
whether they contribute in person, via email or by other means.
The requirement applies to all IPR of the participant, the
participant's employer, sponsor, or others represented by the
participants, that is reasonably and personally known to the
participant. No patent search is required.
Section 1 defines...
END
* Pete Resnick suggested to put back the material from
RFC 3979 Section 4.1 that were deleted from the
previous RFC (April 11), which we’ve also done.
4(D) in the new version. Thanks for that. I see that the section title
and first sentence of 4(D) are the text from -08 instead of the original
text from 3979. That's OK, but personally, I think the section title has
gotten unwieldy and the changes to the first sentence make it somewhat
less clear. I'd suggest just eliminating the title (so it matches the
form of A, B, and C) and putting the example into the first sentence:
OLD
D. Determination of Provision of Reasonable and Non-discriminatory
Terms
The IESG will not make any determination that any terms for the
use of an Implementing Technology has been fulfilled in practice.
It will instead...
NEW
D. The IESG will not make any determination that any terms for the
use of an Implementing Technology (e.g., the assurance of
reasonable and non-discriminatory terms) has been fulfilled in
practice. It will instead...
END
* Note that Pete Resnick had a concern on forcing people to
document applicability to the contribution 5.4.2 (April 11). This
may
require further discussion, although I personally am inclined to
agree
with Pete. I had posted a response on April 25, for which there
was no other response. Needs further discussion during 2nd last
call.
I am satisfied with the text as written in -10.
* Pete Resnick had a concern on adding the word “all” to Section 7
(April 11). This was an oversight, and has been corrected.
Thanks for that. Personally, I don't think the extra text at the end of
that paragraph that went in as of -09 really adds anything. 3979 already
said that there is a consensus that MTI security must be royalty-free,
so of course there would need to be a consensus to do otherwise. I'm in
favor of sticking to the language of 3979 unless something really
changed or clarification is truly necessary, so I'd ask to remove the
new stuff. That said, I won't go to the mat about this change if folks
want it in there, but if we go with the new text, please fix the typo:
s/in violation if this principle/in violation of this principle
Items from the change notes:
----
update abstract to make it clear that this document replaces RFC
2026
section 10
If we're going to do that, we should probably do it the same way that
3979 did:
OLD
This memo
replaces section 10 of RFC 2026 and obsoletes RFC 3979 and RFC
4879.
NEW
This memo
updates RFC 2026 and, with RFC 5378, replaces Section 10 of
RFC 2026. This memo also obsoletes RFC 3979 and RFC 4879.
END
BTW: Whichever text is used should probably also be used in the last
sentence of the first paragraph of section 2. It still uses the previous
language there.
----
In Sec. 3.1, added sentence about WGs that summarizes ideas from
Sec.
7.
That's fine, but in that sentence, please change "possible" to
"reasonably possible". In other places in the document it's used
informally, but 3.1 is a statement of the "General Policy", so we should
be a bit more precise.
----
In Sec. 6, put back list of penalties since it was pointed out that
RFC 6701 is informational only.
Ugh. This undid a change that was (correctly) done back in -07. The new
text in -07 was definitely ungrammatical and needed fixing. However, I
do not believe that putting back the -06 text is appropriate in light of
the discussion on the list regarding -08. RFC 6701 was Informational for
a reason: It is not introducing any new sanctions. All of the sanctions
are available under already existing IETF processes. A primary reason
6701 was written was because folks at the time didn't understand that
they could be used for this purpose, just like you would use such
remedies for any other disruption of IETF work. But we wanted to be
clear that we weren't making new policy, which is why it's not a BCP.
This document (which is going to be a BCP) shouldn't do anything that
might be interpreted as a new sanctions policy. It reads as if it's
trying to do exactly that, particularly given that the text in this
document lists suspension of posting/participation first in the list,
which is quite contrary to the spirit of 6701. (And let's be honest: The
real penalties in not disclosing lie in those "available under law".) As
was proposed back in March, please change the last paragraph of 6:
OLD
In addition to any remedies or defenses that may be available to
implementers and others under the law with respect to such a
violation (e.g., rendering the relevant IPR unenforceable), the
IESG
may, when it in good faith concludes that such a violation has
occurred, impose penalties including, but not limited to,
suspending
the posting/participation rights of the offending individual,
suspending the posting/participation rights of other individuals
employed by the same company as the offending individual, amending,
withdrawing or superseding the relevant IETF Documents, and
publicly
announcing the facts surrounding such violation, including the name
of the offending individual and his or her employer or sponsor. See
[RFC6701] for details.
NEW
In addition to any remedies available outside the IETF, actions may
be taken inside the IETF to address violations of IPR disclosure
policies; see [RFC6701] for details of the sanctions defined in
various existing Best Current Practice documents.
END
That appeared to be the conclusion of the discussion then, and I didn't
see anything on the list to indicate otherwise. If someone likes the
stuff at the beginning (which I don't particularly think is necessary,
but I won't object to if someone insists), here's an alternative:
NEW
In addition to any remedies or defenses that may be available to
implementers and others under the law with respect to such a
violation (e.g., rendering the relevant IPR unenforceable),
sanctions
are available through the normal IETF processes for handling
disruptions to IETF work. See [RFC6701] for details of the
sanctions
defined in various existing Best Current Practice documents.
END
----
Two other items on minor changes:
In section 1, in the definition of "Contribution", "this definition"
changed to "this specification". I think I see why that was done (to
avoid confusing whether "this definition" is referring to the definition
of "Contribution" or the definition of entire document.) But calling
either of those a "specification" is a bit weird, especially considering
that in context, every other use of "specification" in this document is
about a technical specification. I'd suggest either changing "this
definition" to "this policy" if the intention is the entire document, or
"this definition of Contribution" if that's what's meant.
Also, there were a couple of minor changes in 5.2.2. In both instances,
please change "Covers" to "may Cover". I actually think that makes it
stronger and leaves less ambiguity: What triggers the disclosure is that
you simply realize that IPR *may* cover the contribution; you don't have
to come to some sort of grand final determination that it does surely
cover (and how could you know that for sure anyway?).
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478