Re: Last Call: <draft-bradner-rfc3979bis-10.txt> (Intellectual Property Rights in IETF Technology) to Best Current Practice

[Pete Resnick <[e-mail]>]

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. - [phone]