Re: [sidr] adverse actions -01 posted

Tim Bruijnzeels <tim@ripe.net> Tue, 26 July 2016 14:14 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1482212DF17 for <sidr@ietfa.amsl.com>; Tue, 26 Jul 2016 07:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
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 prC0yTVWGi_U for <sidr@ietfa.amsl.com>; Tue, 26 Jul 2016 07:14:07 -0700 (PDT)
Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEC512DB8C for <sidr@ietf.org>; Tue, 26 Jul 2016 06:57:44 -0700 (PDT)
Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from <tim@ripe.net>) id 1bS2rc-0008GJ-Sr; Tue, 26 Jul 2016 15:57:42 +0200
Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-62.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1bS2rc-0007dr-Nw; Tue, 26 Jul 2016 15:57:40 +0200
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=us-ascii
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <76dad5c8-114a-19fe-6fc2-cf3c45e0f666@bbn.com>
Date: Tue, 26 Jul 2016 15:57:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <227BF007-90BD-4301-A349-FC01A1A5969A@ripe.net>
References: <76dad5c8-114a-19fe-6fc2-cf3c45e0f666@bbn.com>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.3124)
X-ACL-Warn: Delaying message
X-RIPE-Spam-Level: ----------
X-RIPE-Spam-Report: Spam Total Points: -10.7 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071990b5ae4620551a273992e24cd1cf7222
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/ji3X4etorZ2B3GjXy_39rhwspac>
Cc: sidr <sidr@ietf.org>
Subject: Re: [sidr] adverse actions -01 posted
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2016 14:14:12 -0000

Hi Steve, list,

I still have an issue with the word "adverse" used in this document, and especially the first line in the introduction:

   In the context of this document, any change to the Resource Public
   Key Infrastructure (RPKI) [RFC6480] that results in a diminution of
   the set of Internet Numeric Resources (INRs) associated with an INR
   holder contrary to the holder's wishes is termed "adverse".

To me the word "adverse" communicates an unfavourable, possibly even malicious, action by an adversary. It implies that for conscious actions by a parent CA against the will by a child CA, the parent is "wrong" and the child is "right" (the victim of something that is "adverse"). As I said earlier there are circumstances where we as RIPE NCC are bound to reclaim resources from holders against their will. And however "unwanted" this may be by the holder of the resources, this is not because we bear these holders any ill will (and actually in most cases there is no dispute). Reclaiming resources is based on policy discussed in a bottom-up policy development process in our address policy working group. Calling this "adverse" implies that the holder is "right", and RIPE NCC is "wrong" in these cases.

I strongly believe that this document should not take sides. This may be what the authors intended in the first place, but then I would be much more comfortable if the word used was "unwanted". I believe this term is also more appropriate when the cause of the problem is unintentional (an error/glitch).

Tim



> On 25 Jul 2016, at 17:26, Stephen Kent <kent@bbn.com> wrote:
> 
> Folks,
> 
> I have just posted the -01 version of the adverse actions document. It contains the edits I noted in my response to Tim on 7/19, as well as the revisions to the intro in response to feedback from Sandy and Randy.
> 
> Please send any comments on the revised version to the list.
> 
> I want to thank Daiming Li of ZDNS for transforming my revisions into a new .txt file suitable for posting.
> 
> Steve
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr