Re: Gen-ART Last Call review of draft-bradner-rfc3979bis-08

Pete Resnick <> Wed, 30 March 2016 01:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AED0F12D183; Tue, 29 Mar 2016 18:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4QbHHNSs7Xrz; Tue, 29 Mar 2016 18:38:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C5FB012DC03; Tue, 29 Mar 2016 18:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1459301927; x=1490837927; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=oWEaPhvKEvMmuJpAwW4Bj24jf/+RtFo0fn8zHb3KAZ8=; b=uhAcNN6QAptUMSXavyockhkaXfGt9x4xtbZCcWcVB3qWnp7e7M/Ql8ya SrrySzjpTQ9yd6TwnJHYbhW8DaIQv3hbPZUMrZt5vtEkr4FtTjoFLfqtD +KXyLhTUPZDfCoiM5hieG1G6dhsFhYd04Q6uU4SAIuHU4jlrN0YiZcZmR Y=;
X-IronPort-AV: E=Sophos;i="5.24,414,1455004800"; d="scan'208,217";a="275539618"
Received: from unknown (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Mar 2016 18:38:47 -0700
X-IronPort-AV: E=McAfee;i="5700,7163,8119"; a="1165750396"
Received: from ([]) by with ESMTP/TLS/RC4-SHA; 29 Mar 2016 18:38:47 -0700
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 29 Mar 2016 18:38:46 -0700
From: Pete Resnick <>
To: Brian E Carpenter <>
Subject: Re: Gen-ART Last Call review of draft-bradner-rfc3979bis-08
Date: Tue, 29 Mar 2016 20:38:44 -0500
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_E67FD94B-D7D6-4443-992A-A35002D3D81F_="
X-Mailer: MailMate (1.9.4r5239)
X-Originating-IP: []
X-ClientProxiedBy: ( To (
Archived-At: <>
Cc: General Area Review Team <>, IETF discussion list <>,
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Mar 2016 01:38:50 -0000

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

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

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

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

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.

And on the specific suggestion:

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

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.

Pete Resnick <>
Qualcomm Technologies, Inc. - +1 (858)651-4478