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

From: Russ Housley <[email-masked]>
Date: Tue, 7 Feb 2017 11:16:56 -0500

I reviewed draft-bradner-rfc3979bis-11, and I have come comments and some nits.

Comments …

In Section 1, definition b, please  update the bullet about deign teams to:

	o any WG design teams [see BCP 25] and other design teams that intend to deliver an output to the IETF,

In Section 1, definition j, please be more specific in the reference.  I think the intention is to reference Section 2.2 of [RFC2026].

In Section 5.5, paragraph D, I suggest a different wording:

      D. Licensing declarations must be made by people with appropriate
          authorization as discussed in Section 5.6 of this document.

In Section 7, please provide pointers for FRAND, RAND, and RAND-z.

In Section 11, please drop “legal” from the first sentence in the second paragraph:

   The rules that apply ...

Nits …

I see “this memo” and “this document”.  Either one is fine with me, but please pick one and use it throughout.

Section 2: s/IETF and its Participants/IETF and IETF Participants/

Section 5.2.3:  s/IETF area directors/IETF Area Directors/

Section 5.3: s/RFC-Editor/RFC Editor/

Please remove the period at the end of the heading for Section 5.4.2.

Section 5.4.2: s/drafts/Internet-Drafts/

Section 5.4.2, paragraph A:
   s/application (3)/application, (3)/
   s/application ), (4)/application, (4)/

Section 5.4.2, paragraph D:
   s/submit to IETF an update/submit an update/
   s/Secretariat/IETF Secretariat/ (several places)

Section 5.5, paragraph A: s/non- discriminatory/non-discriminatory/

Section 5.6:
   s/IPR that is (a) owned/IPR that (a) is owned/
   s/ or (b) that such persons/; or (b) persons/
   s/ or (c) that such persons/; or (c) persons/
   s/, or (d) in the case of an individual, the individual/; or (d) an individual/

Section 6: s/violation of IETF process/violation of the IETF Standards Process/

Section 7: s/Working groups and areas may/IETF Areas and IETF working groups/

Russ

---

From: Jari Arkko <[email-masked]>
Date: Wed, 22 Feb 2017 23:40:56 +0200

All,

I have gone through the discussion. Here’s what I’d like to conclude,
and have told the editors to take these into account in a new version.
I have asked a version to  be published, and see if we can get that
approved in the next IESG telechat(s).

SUBSTANTIAL

* Comment from Russ Housley on Jan 19, regarding design
  teams and when the IETF work starts.

>> * Russ Housley’s concern re: “IETF sanctioned” was resolved

>> per Brian’s and Harald's suggestions (Brian's mail on March 26).

> I do not think that the change here is sufficient based on my reading of the thread that followed my comments.  I think my comment is addressed, but not all of the points that are made in that thread.  In particular, the output of the design team is the contribution, not every alternative that is discarded before being written down or presented.  Also, the reference to BCP 25 seems to scope this the design teams in working groups, not all design teams.

Further discussion in the thread resulted in this suggested change:

Perhaps: “… WG design teams [see BCP 25] and other design teams that
intend to deliver an output to the IETF …”

* Comment from Stewart Bryant on Jan 24, regarding item j in
  Section 1:

>   j. "Internet-Draft": a temporary document used in the IETF and RFC

>      Editor processes, as described in [RFC2026].

> SB> IDs are no longer temporary documents. There was a myth that

> SB> were temporary long after they were unofficially archived, but they

> SB> are now formally archived by the tools system. This is important

> SB> because they have a potential influence that stretches beyond

> SB> the notional six months.

Stewart is factually right here. I’d propose deleting the word and
saying nothing about the documents’ permanence or lack thereof.
The deletion was also supported by Brian Carpenter on IETF
list discussion. This RFC-to-be is not the place that discusses
IETF I-D storage practices so I don’t think we need to explain
what the situation is, just not incorrectly refer to it :-)

* Comment from Stewart Bryant on Jan 24:

>   5.2.3      Timing of Disclosure by ADs

>   By the nature of their office, IETF area directors may become aware

>   of Contributions late in the process (for example at IETF Last Call

>   or during IESG review) and, therefor and in such cases, cannot

>   reasonably be expected to disclose IPR Covering those Contributions

>   until they become aware of them.

> SB> I made the following point as an input via another route.

> SB>

> SB> There are a number of people that would not ordinarily be expected

> SB> to see a document until the very late stages of the process.

> SB> The Gen-art reviewers, and the directorates doing cross are

> SB> reviews. It would seem reasonable to give dispensation to all

> SB> of the groups assisting the ADs in late stage reviews where

> SB> the reviewer took no part in the development of the document.

> SB>

> SB> Either the above or strike the section.

Stewart has a point here as well. Brian Carpenter suggested:

  By the nature of their office, IETF area directors or persons assisting
  them may become aware of Contributions late in the process …

so lets do that.

* Comment from Stewart Bryant on Jan 24 on Section 5.4.1:

> 5.4.1. Content of IPR Disclosures

>   The IPR disclosure must

>   also list the name(s) of the inventor(s) (with respect to issued

>   patents and published patent applications) and the specific IETF

>   Document(s) or activity affected.

> SB> It is new to require the names of inventors. Given that the names

> SB> of inventors are in the published patent it would seem reasonable

> SB> to follow the principle of minimizing the actions required by

> SB> organizations outside the IETF and not add this requirement.

There has been considerable discussion on including the names
supporting the addition, and there’s a rationale for this addition,
relating to for instance, the easy ability to identify IETF participants.
There are also translation concerns when patent filings incl.
inventor names are not easily readable.

I’d suggest no changes here.

* Comment from Stewart Bryant on Jan 24 on Section 5.4.1:

>   If the IETF Document is an

>   Internet-Draft, it must be referenced by specific version number.

> SB> That is presumably the version number in which the IPR was

> SB> first observed by the IPR owner. You cover updates later

> SB> but it may be useful to clarify upfront that you do not expect

> SB> per version IPR refresh.

You are right, but I think we are already covered for this in the
draft. The text later says:

      An IPR disclosure must be updated or a new disclosure made
      promptly after any of the following has occurred …  (4) a material
      change to the IETF Document covered by the Disclosure that
      causes the Disclosure to be covered by additional IPR

In other words, no need to update unless there was a material change.

* Comment from Stewart Bryant on Jan 25 on Section 5.4.1:

>>>   An IPR disclosure must list the numbers of any issued patents or

>>>   published patent applications or indicate that the disclosure is

>>>   based on unpublished patent applications.  The IPR disclosure must

>>>   also list the name(s) of the inventor(s) (with respect to issued

>>>   patents and published patent applications) and the specific IETF

>>>   Document(s) or activity affected.

>>> In some cases that is simply impractical. For example one might

>>> know that IPR was filed at a previous employer, for example

>>> because you were on the patent review panel, but of course

>>> would no longer have access to the documents to tease out the

>>> exact identity of the patent. All that we can expect by the first

>>> stage discloser, perhaps filing a third party disclosure, is as

>>> much information as they still have available.

>> Right. Is there a possibility to have a different rule for 3rd party and

>> “regular” declarations?

> The text has a must, whereas the discloser can only provide that information

> as far as practical and with regard to the access to records they have available

> to them at the time they identify the need to disclose.

Perhaps the right thing to do here is to add a constraint
on information available to the person making the disclosure.

How about this:

Add to the end of Section 5.4.1 a new paragraph:

Note that there may be cases — such as third party declarations —
where person making the declaration may not have all the
information. The requirements of this section only apply to
the information that is available to the person(s) making the
declaration.

* Pete Resnick’s review noted the following about Section 2:

>> * 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

These should be adopted, as previously discussed.

* Pete Renisck’s review noted the following on January 26:

>> 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

He seems right. Please use the text (the first “NEW” block above).

>          authorization as discussed in Section 5.6 of this document.

These should be adopted.

OTHER OBSERVATIONS AND QUESTIONS

* Observation from Stewart Bryant on Jan 24, regarding item e in
  Section 1:

>   e. "IETF": In the context of this document, the IETF includes all

>      individuals who participate in meetings, working groups, mailing

>      lists, functions and other activities which are organized or

>      initiated by ISOC, the IESG or the IAB under the general

>      designation of the Internet Engineering Task Force or IETF, but

>      solely to the extent of such participation.
> SB> I think this is a definition of so called "members of the IETF"
> SB> Certainly the term "IETF" on its own means a multitude of things
> SB> to different people and is easily confused.

This definition style is unchanged since the previous RFC. I see
no reason to make changes in this regard.

* Question from Stewart Bryant on Jan 24, regarding item B in
  Section 3.3:

>   B. Such Contributor represents that there are no limits to the
>      Contributor's ability to make the grants, acknowledgments and
>      agreements herein that are reasonably and personally known to the
>      Contributor.
> 
> SB> I do not understand what point B above means.

It means that if you (for instance) make an IPR declaration
and say something about the license conditions, you or whoever
is helping you to make that statement, can actually make those
statements.

I don’t think a document change is needed.

* Suggestion from Stewart Bryant on Jan 24, regarding Section
  5.4.2

>   A. An IPR disclosure must be updated or a new disclosure made

>      promptly after any of the following has occurred unless sufficient

>      information to identify the issued patent was disclosed when the

>      patent application was disclosed: (1) the publication of a

>      previously unpublished patent application, (2) the abandonment of

>      a patent application (3) the issuance of a patent on a previously

>      disclosed patent application ), (4) a material change to the IETF

>      Document covered by the Disclosure that causes the Disclosure to

>      be covered by additional IPR. If the patent application was

>      abandoned, then the new IPR disclosure must explicitly withdraw

>      any earlier IPR disclosures based on the application.  IPR

>      disclosures against a particular Contribution are assumed to be

>      inherited by revisions of the Contribution and by any RFCs that

>      are published from the Contribution unless the disclosure has been

>      updated or withdrawn.

> SB> The above is ideal, but I seriously wonder if a busy IPR group

> SB> will provide update (2) and (3). Given the application number

> SB> anyone interested can find the (2)and (3) for themselves.

> SB> Again the principle of minimizing the work of third parties

> SB> applies.

I think I mostly agree personally. But without further input from others,
I don’t think a change is warranted.

* Question from Stewart Bryant on Jan 24, regarding Section
  5.7:

> 5.7. Disclosures for Oral Contributions.

>   .... then the Contributor must accompany

>   such oral Contribution with an oral declaration that he/she is aware

>   of relevant IPR in as much detail as reasonably possible

> SB> I do not recall ever seeing a purely verbal disclosure, and wonder

> SB> what the process is, how this is archived and how it is discovered?

Sometimes it happens that a presenter makes a statement,
e.g. that the audience should note that some IPRs may apply
and that a written declaration is forthcoming.

* Question from Stewart Bryant on Jan 24, regarding Section
  6:

> 6. Failure to Disclose

>   There may be cases in which individuals are not permitted by their

>   employers or by other factors to disclose the existence or substance

>   of patent applications or other IPR.  Since disclosure is required

>   for anyone making a Contribution or participating in IETF activities,

>   a person who is not willing or able to disclose IPR for this reason,

>   or any other reason, must not contribute to or participate in IETF

>   activities with respect to technologies that he or she reasonably and

>   personally knows to be Covered by IPR which he or she will not

>   disclose, unless that person knows that his or her employer or

>   sponsor will make the required disclosures on his or her behalf.

> SB> Doesn't this have implications for those that work or have

> SB> previously worked in the defence sector? Do we really wish

> SB> to potentially exclude such individuals? I am not sure how

> SB> we deal with the situation, but I am concerned about unintended

> SB> consequences here.

I think this is a choice that the community has wished to make,
and I personally believe it is also the only thing we can actually
do. It is not about excluding anyone, but the IETF’s IPR rules
are actually very easy to satisfy for most participants (cf. SDOs
that would require granting RF license to other members of the
SDO, for instance). If this fundamental basis cannot be complied
to, then maybe it is best that one stays away from that topic. Do
note that it is indeed just that topic, not the whole IETF.

* Observation from Stewart Bryant on Jan 24, regarding Section
  7:

> 7. Evaluating Alternative Technologies in IETF Working Groups

>   In general, IETF working groups prefer technologies with no known IPR

>   claims or, for technologies with claims against them, an offer of

>   royalty-free licensing.  However, to solve a given technical problem,

>   IETF working groups have the discretion to adopt a technology as to

>   which IPR claims have been made if they feel that this technology is

>   superior enough to alternatives with fewer IPR claims or free

>   licensing to outweigh the potential cost of the licenses. To assist

>   these working groups, it is helpful for the IPR claimants to declare,

>   in their IPR Declarations, the terms, if any, on which they are

>   willing to license their IPR Covering the relevant IETF Documents.

> SB> I really do not see how a WG can properly apply the above considerations

> SB> given that it is not permitted to discuss the financial terms

> SB> of the licence.

> SB>

> SB> Historically this may have been less important, but with IoT this changes.

> SB> what would be a reasonable cost in a core router can be a showstopper

> SB> in a $1 device.

Perhaps, but I don’t see another alternative. Standards organisations
cannot really become the negotiation platform for IPR costs, for
a myriad of reasons starting from competition law.

* Question from Stewart Bryant on Jan 24, regarding Section
  12:

> 12. Security Considerations

>   This memo relates to IETF process, not any particular technology.

>   There are security considerations when adopting any technology,

>   whether IPR-protected or not.  A working group should take those

>   security considerations into account as one part of evaluating the

>   technology, just as IPR is one part, but there are no known issues of

>   security with IPR procedures.

> SB> I wonder if this is entirely correct. How about someone who owns

> SB> IPR silently waiting until deployment and then getting an IPR

> SB> based shutdown order? With nations and quasi nations applying unconventional

> SB> warfare, I suspect that there is a potential IPR attack vector.

I think we are already covered for that. You have to declare if
you are a participant, or else you are breaking the rules. Once
you break the rules, but still attempt to use the court system
to collect license fees, your actions will be picked out and
potentially used against you. And if you are not a participant,
no rules that IETF can employ apply to you.

There is no question IPR claims cannot have economical and
other impacts, and the behaviour of the players certainly
affects this. I don’t think we need to write this in the RFC,
however.

* David Rudin asked the following about two implementations on
  January 26:

> "If the two unrelated implementations of the specification that are required to advance from Proposed Standard to Standard have been produced by different organizations or individuals, or if the "significant implementation and successful operational experience" required to advance from Proposed Standard to Standard has been achieved, the IESG will presume that the terms are reasonable and to some degree non-discriminatory. Note that this also applies to the case where multiple implementers have concluded that no licensing is required."

> It's not clear to me what IETF gains by making this presumption, especially given that the availability of two or more implementations does not mean that the implementers did any patent due diligence or licensing around the implementation.  It does, however, potentially expose IESG to risks in the event of patent litigation if implementers are basing their decisions on IESG's presumption.

As noted by Scott, these requirements are not new. Scott also argued that the
time for changing this assumption is not now. And I agree. And Brian Carpenter
opposed changing the assumption, on the basis of practical evidence rather
than getting into the business of validating claims or assessing license conditions.

I made some additional questions to a few participants in the discussion,
and found out that changes in text would cause indigestion for several
participants. Hence I recommend no changes.

EDITORIAL

* Suggestions from Brian Carpenter in private e-mail on Jan 15:

>> [1]Eggert [2]Resnick
> 
> These citations are a bit mysterious…

Remove. That was an oversight.

* Question from Stewart Bryant on Jan 24, regarding the list in
  Section 1 item b.

> SB> It is interesting that you exclude WG Chairs from the list of

> SB> officials that you call out, and yet they can be a key player in

> SB> in deciding whether an encumbered technology progresses or not.

> SB>

> SB> Would it not be cleaner to express this in terms of "officials”?

I will leave this to the editors to adopt or not, but I personally
would be OK adding “A working group chair(s), on behalf of their
work working group”.

* Suggestions from Pete Resnick in private e-mail on Feb 2:

> 16 1.m: s/features/permanence

Adopt

> 16 5.6: s/n/In

Adopt

> 16 8: Got the section number and title wrong here. It should say, "9. - Licensing Requirements (was 10) - Wording updated to reflect RFC 6410”

Adopt

> The first sentence of 5.4.2(A) is really hard to read because there's a long subordinate clause. I think it would read better if you used the same words and just reversed the order:

> OLD

> A. An IPR disclosure must be updated or a new disclosure made

> promptly after any of the following has occurred unless sufficient

> information to identify the issued patent was disclosed when the

> patent application was disclosed:

> NEW

> A. Unless sufficient information to identify the issued patent was

> disclosed when the patent application was disclosed, an IPR

> disclosure must be updated or a new disclosure made promptly after

> any of the following has occurred:

> END

Adopt.

* Suggestion from Stewart Bryant on Jan 24, regarding Section
  5.5:

> 5.5. Licensing Information in an IPR Disclosure

>   A. Since IPR disclosures will be used by IETF working groups during

>      their evaluation of alternative technical solutions, it is helpful

>      if an IPR disclosure includes information about licensing of the

>      IPR in case Implementing Technologies require a license.

>      Specifically, it is helpful to indicate whether, upon approval by

>      the IESG for publication as an RFC of the relevant IETF

>      specification(s), all persons will be able to obtain the right to

>      implement, use, distribute and exercise other rights with respect

>      to an Implementing Technology a) under a royalty-free and

>      otherwise reasonable and non- discriminatory license, or b) under

>      a license that contains reasonable and non-discriminatory terms

>      and conditions, including a reasonable royalty or other payment,

>      or c) without the need to obtain a license from the IPR holder

>      (e.g., a covenant not to sue).

> SB> One of the most popular IPR terms is so called MAD. It is surprising

> SB> that you do not call this out.

> …

>   Some common

>   conditions include 1) terms that are fair, reasonable and non-

>   discriminatory, and which may bear royalties or other financial

>   obligations (FRAND or RAND); 2) royalty-free terms that are otherwise

>   fair, reasonable and non-discriminatory (RAND-z); and 3) commitments

>   not to assert declared IPR.

> SB> One of the most common (at least in the Routing area) is non-assert

> SB> unless the other party asserts (so called MAD)

Personally, I don’t view MAD as a term quite in the same style
and technical specificity as, say, RAND or RF. I would suggest
not adopting this.

(Non-assert on the other hand is a more
technical term, but I also have not seen calls for adding that
from others.)

* Editorial suggestions from Brian Carpenter in his Gen-ART review
   on January 26:

>> 7. Evaluating Alternative Technologies in IETF Working Groups

> ...

>> technology in violation if this principle if there is a very good

> s/if this principle/of this principle/

Adopt

>> 13. Changes Since RFC 3979 and RFC 4879

>> 16. Changes Since RFC 3979

> Should the preamble to these sections state that they are provided

> for informational purposes only and that in case of doubt the text

> of sections 1-12 prevails?

> Should these two sections be merged?

Yes. Adopt both suggestions.

* Pete Resnick’s review suggested the following edits
  to Section 4.1:

>> * 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

These should be adopted.

* Pete Resnick’s review said:

>> * 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

I think we are OK either way, and I will leave the choice to the editors.

* Pete Resnick notes about 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.

These should be adopted.

* Pete Resnick’s minor editorial suggestions from January 26:

> 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.

Please adopt “this policy”.

* Pete Resnick’s minor editorial suggestions from January 26:
> 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?).
> 

Right. Adopt this.

>   The rules that apply …

These should be adopted.

> Section 7: s/Working groups and areas may/IETF Areas and IETF working groups/

These should be adopted.

Jari

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 24 Feb 2017 10:45:48 +0000

Jari

I agree with the proposed resolutions , but would like to reply on three 
points:

>     I don’t think a document change is needed.

I am suspect that I am not alone in finding the original legal language
impenetrable, whilst finding your explanatory text crystal clear. I would
request you take a another look at this point, perhaps adding your text
by way of clarification.

>     and that a written declaration is forthcoming.

I suppose the requirement would that the WG take particular care to 
minute the IPR
disclosure so it is on record. At least if it is the minutes it is 
searchable and from
the minutes you can get to the recoding to get the exact words.

>     technical term, but I also have not seen calls for adding that

The reason I raise this is because it is the most common licensing term 
in the lower layers
being the standard term by at least three of the major vendors. I am 
sure it has a technical
name, presumably mutual-non-assert.

- Stewart