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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 30 March 2016 01:57 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3326312DC33; Tue, 29 Mar 2016 18:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqsUEWTH6QeB; Tue, 29 Mar 2016 18:57:45 -0700 (PDT)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624FA12D8D0; Tue, 29 Mar 2016 18:57:45 -0700 (PDT)
Received: by mail-pf0-x22a.google.com with SMTP id x3so29167076pfb.1; Tue, 29 Mar 2016 18:57:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.98.68.91 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 smtp.gmail.com with ESMTPSA id lq10sm1199422pab.36.2016.03.29.18.57.41 (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 <presnick@qti.qualcomm.com>
References: <56F6F0D6.9090300@gmail.com> <9928323F-BBDA-475B-B3E5-442676405C5B@qti.qualcomm.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <56FB3298.9040209@gmail.com>
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: <9928323F-BBDA-475B-B3E5-442676405C5B@qti.qualcomm.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/WciHg0jrz2vKONzEJd_g6CdjDEI>
Cc: General Area Review Team <gen-art@ietf.org>, IETF discussion list <ietf@ietf.org>, draft-bradner-rfc3979bis.all@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=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".

    Brian

> 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