ietf
[Top] [All Lists]

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

2017-01-27 09:51:05
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
<Prev in Thread] Current Thread [Next in Thread>