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

From: Jari Arkko <[email-masked]>
Date: Wed, 18 Jan 2017 16:52:22 +0200

You’ve seen the last call message come through, but as
the AD responsible for this document, I wanted to follow-up
with a description of where I think we are with the document.

This document went through a last call process in spring 2016,
with a fair number of comments. We’ve taken the feedback
in, and being less busy with the transition work that was undergoing
last summer, have returned with a new document that we
believe addresses those issues. The changes are substantial
enough though that we think that a new last call is necessary.

Note that given some textual reorganisation, the document is
difficult to compare to the original RFC. There is a changes
section, but having a more detailed listing would be beneficial.
We have promised to provide this detailed section, and will do
so within a week from now.

The spring 2016 comments have been listed in

https://www.ietf.org/mail-archive/web/ietf/current/msg100236.html

along with some tentative solutions that were given
for the editors. With some further discussion, I’m listing
the main changes to the document from the previous
last call below:

* Stephen Farrell’s concern re: remote vs. in-person attendees
  was resolved without text changes (Jari’s mail on March 22)

* Russ Housley’s concern re: “IETF sanctioned” was resolved
  per Brian’s and Harald's suggestions (Brian's mail on March 26).

* Russ Housley’s concern re: changes from the previous RFC
  section is valid (Russ’s mail on March 25), and we will be acting
  on that as explained above.

* Gonzalo Camarillo’s concern re: ADs being assumed to read
  all documents in their area seemed valid and was fixed.

  We think that is incorrect if the future BCP on this topic explicitly
  rules everything in the area to be something where the AD
  participates in, even if he or she might not even be the AD
  for the group in question.

  We used a variation Spencer’s wording (Spencer’s mail on
  March 30).

  OLD:
  Without limiting the generality of the foregoing, acting as a
  working group chair or Area Director constitutes “Participating"
  in all activities of the relevant working group or area.
  NEW:
  Without limiting the generality of the foregoing, acting as a
  working group chair or Area Director constitutes “Participating"
  in all activities of the relevant working group or working groups
  he or she is responsible for in an area.

* A follow-up to Gonzalo’s concern was raised later in the
  discussion re: ADs often seeing the materials late in the process.
  There seemed to be support for adding this to the document, which
  we have done:

  NEW:
  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, therefore and in such
  cases, cannot be expected to disclose any IPR Covering those
  Contributions until they become aware of them.

* Alissa Cooper’s editorial comments from her mail on April 1
  were acted up, except the first issue which was follow-up to
  Gonzalo’s issue.

* There was some discussion of including the IRTF in the document
   in the same go, but the authors and the AD came to the
   conclusion that it introduces too many dependencies.

   Also, worth discussing during the last call, is that the new document
   refers to stream managers that have not really been well defined
   elsewhere.

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

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

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

* Pete Resnick had a concern on adding the word “all” to Section 7
  (April 11). This was an oversight, and has been corrected.

* Section 7 has been amended to be clear that its latter part is for
  information only.

The changes to spring 2016 version of the I-D can be seen here:
https://www.ietf.org/rfcdiff?url1=draft-bradner-rfc3979bis-08&url2=draft-bradner-rfc3979bis-10

Jari Arkko, sponsoring AD for draft-bradner-rfc3979bis

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 18 Jan 2017 15:25:52 +0000

Scott,

In the body of this document you say:

j. "Internet-Draft": a temporary document used in the IETF and RFC
       Editor processes, as described in [RFC2026].

RFC2026 states that the drafts are removed from the directory, implying
that after that time they are not available. Whilst that never really
reflected reality, the IETF through its tools system actively makes these
documents available in perpetuity. Given the legal nature of this draft
we ought to properly note the permanent availability of these temporary
documents.

Section 5.3.3 specifically calls out ADs but there are many others who
fall into the same category: the GEN_ART team, the directorates of
other areas such as SEC and OPS, and of course regular contributors that
only read an out of area RFC when they need to use its contents.

If the text is specifically going to call out ADs it ought to also call
out those that help ADs as part of their review process.

The test says:

    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.

In section 7 you state

    When adopting new technologies, the participants in an IETF working
    group are expected to evaluate all the relevant tradeoffs from their
    perspective. Most of the time these considerations are based purely
    on technical excellence, but IPR considerations may also affect the
    evaluation and specific licensing terms may affect the participants'
    opinion on the desirability of adopting a particular technology.

There is a catch 22 problem with this text and later text in the section.
The IPR situation may indeed affect an adoption decision, but the WG
is not allowed to discuss the terms of the licence. In some cases the
terms of an encumbered technology may be just fine, but
contributors making an adoption decision cannot form a view
on this as part of the IETF process. So you can end up with
one partly saying yes because of IPR, another saying no
because of IPR and neither allowed to explain their position as
part of the IETF process.

- Stewart

On 18/01/2017 14:18, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Intellectual Property Rights in IETF Technology'
>    <draft-bradner-rfc3979bis-10.txt> as Best Current Practice
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2017-02-15. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     The IETF policies about Intellectual Property Rights (IPR), such as
>     patent rights, relative to technologies developed in the IETF are
>     designed to ensure that IETF working groups and participants have as
>     much information as possible about any IPR constraints on a technical
>     proposal as early as possible in the development process. The
>     policies are intended to benefit the Internet community and the
>     public at large, while respecting the legitimate rights of IPR
>     holders.  This memo sets out the IETF policies concerning IPR related
>     to technology worked on within the IETF.  It also describes the
>     objectives that the policies are designed to meet.  This memo
>     replaces section 10 of RFC 2026 and obsoletes RFC 3979 and RFC 4879.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-bradner-rfc3979bis/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-bradner-rfc3979bis/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>      rfc6701: Sanctions Available for Application to Violators of IETF IPR Policy (Informational - IETF stream)
>      rfc4844: The RFC Series and RFC Editor (Informational - IAB stream)
>      rfc6401: RSVP Extensions for Admission Priority (Proposed Standard - IETF stream)
> Note that some of these references may already be listed in the acceptable Downref Registry.
>
>

---

From: Russ Housley <[email-masked]>
Date: Thu, 19 Jan 2017 10:09:56 -0500

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

>  on that as explained above.

I look forward to seeing this text.  Since it does not exist yet, I think the IETF Last Call should be extended for two weeks beyond the availability of this text.

Russ

---

From: Jari Arkko <[email-masked]>
Date: Sun, 22 Jan 2017 09:15:58 +0200

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

Hmm. I think I agree with regards to BCP 25 (do you have alternative
references or words?)

But I re-read the thread this morning, and a number of important
points were made along the way in the discussion. However, I
viewed some of those points as possible alternative ways to
tackle the original concerns, and there was a lot of back-and-
forth regarding them. For instance, John Klensin argued
that an output would necessarily be a contribution anyway.

The difficulty here is of course that we want to enable what
John and Brian and Sam talked about, that there are
gatherings that we want to enable that are not yet
IETF design teams but whose discussion may eventually
lead to some IETF design team or submission. Many of
my discussions with other industry people are that way:
“do you have this problem” or “how can we work together
to connect our gear”… and only some fraction of the time
these result in ideas for standards and IETF standards in
particular.

Ultimately, you have to draw a line somewhere. “This
is where IETF work starts and you are now under the
IETF IPR rules”.

Harald’s email from spring I thought outlined this in
practise very nicely:

If the documents clearly define the term "design team" as teams that are
created by a decision in an IETF process, I have very few problem
extending "IETF contribution" to contributions to the design team.

If (as I've sometimes seen) everyone who meets to hash out an idea wants
to call themselves + their friends is a "design team", then I see a
problem with the extension.

The lunchtime "bar BOF" would be a nice test case - arranged by WG
chairs over the WG (or IETF non-WG) mailing list, it would be an IETF
activity with IETF contribution; arranged between friends on the way out
of the preceding WG meeting, it would (I think) not be.

So where does all this leave us?

I’d argue that the output/non-output distinction isn’t the crucial
one. Outputs from design teams that go to the IETF are in any
case covered. But how do we want to cover the design team
discussion (incl. any silly alternatives), without impacting
my ability to have a discussion with my customer for instance?

I think I’d be happy if w extended the BCP 25 reference to
some other text that covers also non-WG design teams, for
instance teams that call themselves IETF design teams (whether
“sanctioned" or not).

But your suggestions are welcome.

> I look forward to seeing this text.  Since it does not exist yet, I think the IETF Last Call should be extended for two weeks beyond the availability of this text.

We are working on it. My hope is that we’ll get it done soon enough for
there to be more than two weeks left of the last call, but if not we will
certainly extend the Last Call.

Jari

---

From: Russ Housley <[email-masked]>
Date: Sun, 22 Jan 2017 13:07:33 -0500

> But your suggestions are welcome.

I agree with the message you quote from Harald.

Text suggestions: … WG design teams [see BCP 25] and other design teams …

> certainly extend the Last Call.

Thanks.

Russ

---

From: Jari Arkko <[email-masked]>
Date: Sun, 22 Jan 2017 20:33:58 +0200

> Text suggestions: … WG design teams [see BCP 25] and other design teams …

Close, thank you!

(But how about adjusting as follows: “… WG design teams [see BCP 25] and other design teams intended as IETF design teams …” ?)

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 23 Jan 2017 08:30:54 +1300

> (But how about adjusting as follows: “… WG design teams [see BCP 25] and other design teams intended as IETF design teams …” ?)

Somebody could check with a lawyer about how to wordsmith it, but I think
it is indeed a question of intent. And maybe participants should be
advised to make their intention clear when starting a discussion, or
to ask when joining a discussion ("Hi, is this an IETF conversation
or a private one?").

    Brian

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sun, 22 Jan 2017 14:31:37 -0500

the lawyer (Jorge) is in the loop here

Scott

> On Jan 22, 2017, at 2:30 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Jan 2017 07:35:25 -0500

> (But how about adjusting as follows: “… WG design teams [see BCP 25] and other design teams intended as IETF design teams …” ?)

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

Russ

---

From: Jari Arkko <[email-masked]>
Date: Wed, 25 Jan 2017 09:42:38 +0200

Stewart,

> we ought to properly note the permanent availability of these temporary

OK. Do you have a text suggestion, or would dropping “temporary” in this
context be sufficient?

> only read an out of area RFC when they need to use its contents.

Fair point.

> much information as they still have available.

Right. Is there a possibility to have a different rule for 3rd party and
“regular” declarations?

> part of the IETF process.

Good point. But I see no way around that. There are plenty of
good reasons why negotiation about license is not a good
idea to do in IETF.

Also, end results matter. If a draft fails to be adopted,
I’ve seen companies post not just updated drafts but
also updated declarations that ultimately led to adoption.

That’s a fine mode of operation, and one way out of your
catch-22.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 25 Jan 2017 09:43:37 +0200

Stewart,

Fair point.

Jari

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Jan 2017 10:07:14 +0000

> OK. Do you have a text suggestion, or would dropping “temporary” in this

Well we could tell the whole story: they are a temporary document for 
the purposes
of actively progressing our work, but are persistent and remain beyond 
the publication of any
RFC for the purposes of traceability.

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

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.

> That’s a fine mode of operation, and one way out of your

I think our historic base is based on a more consistent range of acceptable
costs than we have today, with the introduction or IoT.
Whilst the floor of the IETF is not the place for license fee negotiations
at the moment we are not even allowed to say: "I know that A is better
than B, but a foo cannot afford the licence for A, but can afford it for B".
Instead we would have to say: "I don't want A, I want (inferior) C because
it has no IPR". In other words we currently do not have the ability to
articulate the reason why one approach should be adopted in preference
to another,  other than to express a preference for IPR free. I am 
concerned
that as the scope of the Internet increases this inability to properly
articulate the root issue becomes problematic.

- Stewart

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Jan 2017 13:15:21 +1300

> RFC for the purposes of traceability.

I think just dropping "temporary" is sufficient. We know that I-Ds have
been accepted as prior art in court cases, so it's really irrelevant
for the purposes of the current draft. And I don't think we should do
a backdoor update of RFC 2026 here.

>>> out those that help ADs as part of their review process.

It's section 5.2.3 actually. But I agree, it could read

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

Regards,
   Brian

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 26 Jan 2017 11:00:06 +0000

> a backdoor update of RFC 2026 here.

Dropping temporary would work, but I don't see that telling the truth 
about what
actually happens and has happened for a long time is wrong either. If 
RFC2026 is
out of step with reality on this point,  there is no point in hiding it.

>     them may become aware of Contributions late in the process ...

Yes, that would fix that problem.

- Stewart

---

From: "David Rudin (CELA)" <[email-masked]>
Date: Thu, 26 Jan 2017 20:15:06 +0000

I'd like to better understand the reasoning behind the changes in 4(D).  Previously, the IESG did not make any determination regarding whether terms were reasonable and non-discriminatory.  The new text in that section now includes:

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

David

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Wednesday, January 18, 2017 6:52 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Last Call: <draft-bradner-rfc3979bis-10.txt> (Intellectual Property Rights in IETF Technology) to Best Current Practice

You've seen the last call message come through, but as the AD responsible for this document, I wanted to follow-up with a description of where I think we are with the document.

This document went through a last call process in spring 2016, with a fair number of comments. We've taken the feedback in, and being less busy with the transition work that was undergoing last summer, have returned with a new document that we believe addresses those issues. The changes are substantial enough though that we think that a new last call is necessary.

Note that given some textual reorganisation, the document is difficult to compare to the original RFC. There is a changes section, but having a more detailed listing would be beneficial.
We have promised to provide this detailed section, and will do so within a week from now.

along with some tentative solutions that were given for the editors. With some further discussion, I'm listing the main changes to the document from the previous last call below:

* Stephen Farrell's concern re: remote vs. in-person attendees
  was resolved without text changes (Jari's mail on March 22)

* Russ Housley's concern re: "IETF sanctioned" was resolved
  per Brian's and Harald's suggestions (Brian's mail on March 26).

* Russ Housley's concern re: changes from the previous RFC
  section is valid (Russ's mail on March 25), and we will be acting
  on that as explained above.

* Gonzalo Camarillo's concern re: ADs being assumed to read
  all documents in their area seemed valid and was fixed.

  We used a variation Spencer's wording (Spencer's mail on
  March 30).

  OLD:
  working group chair or Area Director constitutes "Participating"
  working group chair or Area Director constitutes "Participating"

* A follow-up to Gonzalo's concern was raised later in the
  discussion re: ADs often seeing the materials late in the process.
  There seemed to be support for adding this to the document, which
  we have done:

  NEW:

* Alissa Cooper's editorial comments from her mail on April 1
  were acted up, except the first issue which was follow-up to
  Gonzalo's issue.

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

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

* Pete Resnick had a concern on adding the word "all" to Section 7
  (April 11). This was an oversight, and has been corrected.

---

From: "Scott O. Bradner" <[email-masked]>
Date: Thu, 26 Jan 2017 15:42:08 -0500

this is not new - see RFC 3979 section 4.1

Scott

> On Jan 26, 2017, at 3:15 PM, David Rudin (CELA) <[email-masked]> wrote:
>

---

From: "David Rudin (CELA)" <[email-masked]>
Date: Thu, 26 Jan 2017 20:52:37 +0000

Thanks.  Didn't see it in the diff.  But my question remains.  Why is IESG making this presumption?

-----Original Message-----
From: Scott O. Bradner [mailto:[email-masked]] 
Sent: Thursday, January 26, 2017 12:42 PM
To: David Rudin (CELA) <[email-masked]>
Cc: Jari Arkko <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-bradner-rfc3979bis-10.txt> (Intellectual Property Rights in IETF Technology) to Best Current Practice

Scott

> Subject: Re: Last Call: <draft-bradner-rfc3979bis-10.txt> 
> (Intellectual Property Rights in IETF Technology) to Best Current 
> Practice
> 
> * Stephen Farrell's concern re: remote vs. in-person attendees  was 
> resolved without text changes (Jari's mail on March 22)
> 
> * Russ Housley's concern re: "IETF sanctioned" was resolved  per 
> Brian's and Harald's suggestions (Brian's mail on March 26).
> 
> * Russ Housley's concern re: changes from the previous RFC  section is 
> valid (Russ's mail on March 25), and we will be acting  on that as 
> explained above.
> 
> * Gonzalo Camarillo's concern re: ADs being assumed to read  all 
> documents in their area seemed valid and was fixed.
> 
> participates in, even if he or she might not even be the AD  for the 
> group in question.
> 
>  We used a variation Spencer's wording (Spencer's mail on  March 30).
> 
>  OLD:
>  in all activities of the relevant working group or working groups  he 
> or she is responsible for in an area.
> 
> * A follow-up to Gonzalo's concern was raised later in the  discussion 
> re: ADs often seeing the materials late in the process.
>  There seemed to be support for adding this to the document, which  we 
> have done:
> 
>  NEW:
>  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, therefore and in such  cases, cannot be 
> expected to disclose any IPR Covering those  Contributions until they 
> become aware of them.
> 
> * Alissa Cooper's editorial comments from her mail on April 1  were 
> acted up, except the first issue which was follow-up to  Gonzalo's 
> issue.
> 
>  We've done so; we should only make substantive changes  to the 
> original RFC when there's clear consensus to do so.
> 
> * 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.
> 
> * 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.
>

---

From: "Scott O. Bradner" <[email-masked]>
Date: Thu, 26 Jan 2017 15:56:15 -0500

this was worked out at great length many years ago - there may be a time to revisit the assumption but
maybe not right now when we are trying to bring the basic ruleset up to date

Scott

> On Jan 26, 2017, at 3:52 PM, David Rudin (CELA) <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Jan 2017 11:50:18 +1300

> maybe not right now when we are trying to bring the basic ruleset up to date

I'd agree that this is not the moment to revisit something so basic,
but for the record I would oppose changing this. It is a pragmatic way
of avoiding any situation in which the IESG or the IETF is effectively
deciding whether or not a patent claim is valid.

   Brian

---

From: Pete Resnick <[email-masked]>
Date: Thu, 26 Jan 2017 13:06:24 -0800

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.

>   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

>   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

>   was no other response. Needs further discussion during 2nd last 

I am satisfied with the text as written in -10.

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 30 Jan 2017 21:57:18 +0200

Pete:

Thanks for your careful read and comparisons.

I have read through your suggestions and agree with all of them.

Jari