Subject: [Gen-art] Gen-ART Last Call review of draft-bradner-rfc3979bis-08

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Mar 2016 09:28:06 +1300

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-bradner-rfc3979bis-08.txt
Reviewer: Brian Carpenter
Review Date: 2016-03-27
IETF LC End Date: 2016-04-30
IESG Telechat date:

Summary: Almost ready
--------

Comment:
--------

I've been tracking this draft since the start and I'm very supportive of it.

Major issues:
-------------

> 6. Failure to Disclose

This paragraph has been over-pruned; it now makes no sense:

>   In addition to any remedies the IESG may consider other actions. See
>   [RFC6701] for details.

Do you mean:

   In addition to any remedies available outside the IETF, the IESG may
   consider other actions. See [RFC6701] for details.

I'm made a little nervous by the fact that RFC 6701 is Informational,
and the text you have removed would give the IESG specific authority (by BCP)
to impose penalties. So I think you have actually pruned too much. I would
prefer that authority to be included, so maybe:

   In addition to any remedies available outside the IETF, 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.

Minor Issues:
-------------

See [email-masked] discussion on the definition of a Contribution.

Nit:
----

http: should be https: (3 times)

---

From: Jari Arkko <[email-masked]>
Date: Sun, 27 Mar 2016 11:36:40 +0100

Thanks for your review, Brian.

The points you raise are good ones, and we need to deal with them somehow.

Jari

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 27 Mar 2016 16:51:13 -0700

> The points you raise are good ones, and we need to deal with them

I would like to add another point to Brian's review. I am concerned that the "General Policy," as stated in section 3.1, does not really present the IETF consensus. The current text says:

   In all matters relating to Intellectual Property Rights, the intent
   is to benefit the Internet community and the public at large, while
   respecting the legitimate rights of others.

This is a bit misleading. The actual IETF approach is delineated in section 7, where it is explained that working group members are carefully weighting tradeoffs between the potential benefits of using a patented technology, and the potential impediments caused by licensing terms, or the uncertainty about licensing conditions. The purpose of early disclosure is to help working groups make informed decisions as early as possible, by opposition to investing a lot of effort on a particular design before learning about the IPR existence.

Pretty much the entire policy derives from that. So maybe it should be stated upfront!

- -- Christian Huitema

---

From: Jari Arkko <[email-masked]>
Date: Mon, 28 Mar 2016 08:46:57 +0100

Christian,

Thanks for your comments.

> Pretty much the entire policy derives from that. So maybe it should be stated upfront!

I think you are right.

Jari

---

From: Pete Resnick <[email-masked]>
Date: Tue, 29 Mar 2016 20:38:44 -0500

On 26 Mar 2016, at 15:28, Brian E Carpenter wrote:

> may

I think that's fine, but it needn't even refer to the IESG:

    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.

6701 points out that actions can be taken by chairs, ADs, the IESG, or 
the IETF as a whole.

But I'm fine with either of the above.

> prefer that authority to be included, so maybe:

I strongly disagree. Quoting 6701:

    This document discusses these issues and provides a suite of
    potential actions that can be taken within the IETF community in
    cases related to patents.  All of these sanctions are currently
    available in IETF processes, and at least two instances of violation
    of the IPR policy have been handled using some of the sanctions
    listed.

6701 didn't change the sanctions available to the IETF, and this 
document doesn't and shouldn't either. So I disagree that this should to 
be added to this document.

>    of the offending individual and his or her employer or sponsor. See

Part of what I didn't like about the -06 version was that it, like you 
did in the above, only pointed out the most harsh sanctions discussed in 
6701, implying that those are the ones that should be used and not the 
others. A perfectly reasonable sanction, in some cases, is:

    a. A private discussion between the working group chair or area
       director and the individual to understand what went wrong and how
       it can be prevented in the future.

Please, leave it short, with either the short correction at the top from 
either Brian or myself.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Mar 2016 14:57:44 +1300

On 30/03/2016 14:38, Pete Resnick wrote:
> 6701 points out that actions can be taken by chairs, ADs, the IESG, or the IETF as a whole.
> 
> 6701 didn't change the sanctions available to the IETF, and this document doesn't and shouldn't either. So I disagree that this
> should to be added to this document.

Hmm. What that amounts to is indirect normative references to
those sanctions. That's a little baroque for my taste. (Also,
the normative references in 6701 include [BCP79], specified
as the two documents that this draft obsoletes.)

I see your point, though. Would you buy something like this?

"...see [RFC6701] for details of the sanctions defined in
various existing Best Current Practice documents".

    Brian

> Part of what I didn't like about the -06 version was that it, like you did in the above, only pointed out the most harsh
> sanctions discussed in 6701, implying that those are the ones that should be used and not the others. A perfectly reasonable
> sanction, in some cases, is:
> 
> Please, leave it short, with either the short correction at the top from either Brian or myself.
> 
> pr

---

From: Pete Resnick <[email-masked]>
Date: Thu, 31 Mar 2016 15:28:08 -0500

> various existing Best Current Practice documents".

Sure, no objection to that if it makes you more comfortable.

pr

---

From: Jari Arkko <[email-masked]>
Date: Thu, 31 Mar 2016 19:53:39 -0300

> Sure, no objection to that if it makes you more comfortable.

WFM.

Jari