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

Brian E Carpenter <> Wed, 30 March 2016 01:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3326312DC33; Tue, 29 Mar 2016 18:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NqsUEWTH6QeB; Tue, 29 Mar 2016 18:57:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 624FA12D8D0; Tue, 29 Mar 2016 18:57:45 -0700 (PDT)
Received: by with SMTP id x3so29167076pfb.1; Tue, 29 Mar 2016 18:57:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ozsO1pBmQnqXSo1vlsqG3FBcUH3/y8yMjx/Dy8egiAs=; b=lvH1JrzaKsgyIPbuOq31ub4NrLDw74vssTKsBp4HNNJe6BJKZugh0YvPbDXTOexjXF /NBi+UuUILMT1FF6Jhecl0qWt/d/EJP1I7V7xefT6HqI9bzbJkTlPiQ2lTMwn/6ESQE8 VRejUSxzfav7BYNnhdVcvYqm3sOx5ncaHmi1b9eNfb5n+WxVz2jf+hbsvCaKvlszPlmI 5pC61II9+Cck7gENZW20+CebYiXYadfsWncArOpmwZt/JCvAgiBgb2uEDtwN6vaTQAgK OxPjwFOT66/vDktjqT+ysjW+Ub0TyR9NYftewY/ClojeBYi/3onUYgCrq+ptn6sBrnNu ilkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=ozsO1pBmQnqXSo1vlsqG3FBcUH3/y8yMjx/Dy8egiAs=; b=Y3xBoyGvD1mHRU6Sp1TS3yJfkLisF38Y5HJ9VCDRtEWhRuHh4GiXxvcaD5Ze0uLeIE PE2PvOXsmIvCjaSwf//F7503GJY8dWC7XRTElJByngV3K0eEUEk2kJcdkalEJCY1wGSX tKRbL8E00qzC1GqV0mTYX7BcltcFn1V/NY5TY/4ST9aSUlKESkzKp7jWPZnXrB7o/IlH C535mFCuLCViezwWsapsCzGiBribhRKxMbrt+tF6Id+1bpS/xHo2B7pTdfvEiRP/AKZm iEEDo4tcicGNMrAEYv2BFDs8o4EUv2apPwTnvLJf3+9DhyldTUdNBmNNUp2b8zbxqGTb TXJw==
X-Gm-Message-State: AD7BkJKBnzHUPLRxN2z3juR0ppxIULgEW8YIs8ziNPzaKoMln9l8pFK/amdQw7oZ1El3gA==
X-Received: by with SMTP id r88mr8697010pfa.12.1459303064948; Tue, 29 Mar 2016 18:57:44 -0700 (PDT)
Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by with ESMTPSA id lq10sm1199422pab.36.2016. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2016 18:57:44 -0700 (PDT)
Subject: Re: Gen-ART Last Call review of draft-bradner-rfc3979bis-08
To: Pete Resnick <>
References: <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Wed, 30 Mar 2016 14:57:44 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
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:57:47 -0000

On 30/03/2016 14:38, Pete Resnick wrote:
> 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
>    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.

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


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