IETF Logo Mail Archive

Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt

Andy Newton <andy@arin.net> Thu, 16 July 2015 17:04 UTC

Return-Path: <andy@arin.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583CD1ACEA2 for <sidr@ietfa.amsl.com>; Thu, 16 Jul 2015 10:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 eCfTFK6ZAU5M for <sidr@ietfa.amsl.com>; Thu, 16 Jul 2015 10:04:07 -0700 (PDT)
Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC7C1ACE9F for <sidr@ietf.org>; Thu, 16 Jul 2015 10:04:05 -0700 (PDT)
Received: by smtp2.arin.net (Postfix, from userid 323) id 13F8D213A36; Thu, 16 Jul 2015 13:04:05 -0400 (EDT)
Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.arin.net (Postfix) with ESMTP id 5D5A2213A30; Thu, 16 Jul 2015 13:04:04 -0400 (EDT)
Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 16 Jul 2015 13:10:07 -0400
Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0224.002; Thu, 16 Jul 2015 13:04:03 -0400
From: Andy Newton <andy@arin.net>
To: Stephen Kent <kent@bbn.com>
Thread-Topic: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
Thread-Index: AQHQuEvNHLMrleBUIUuX/9bvjtuFEZ3QaWKAgAGwwwCACzWggIABFoQAgAAKowCAADRcAA==
Date: Thu, 16 Jul 2015 17:04:03 +0000
Message-ID: <6FD0DC29-9169-44D7-9152-2F1C0E0458A1@arin.net>
References: <20150530231211.10362.50102.idtracker@ietfa.amsl.com> <m2lhg33u84.wl%randy@psg.com> <556CF530.4010408@ops-netman.net> <m27frn3qye.wl%randy@psg.com> <87F5B607-2ECC-4C54-A8D8-D8CE5F587F07@tislabs.com> <559A8B31.50408@bbn.com> <m2vbdw24mv.wl%randy@psg.com> <559BF347.60609@bbn.com> <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com> <55A6C585.6060602@bbn.com> <8BE719A0-0EC1-4E35-8BAD-A64E06D0979C@arin.net> <55A7B814.1020509@bbn.com>
In-Reply-To: <55A7B814.1020509@bbn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.1.34.130]
Content-Type: multipart/alternative; boundary="_000_6FD0DC29916944D791522F1C0E0458A1arinnet_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/ElmaquYDU0IQvbx119PXP2-vjac>
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] New Version Notification for draft-ymbk-sidr-transfer-00.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 16 Jul 2015 17:04:08 -0000

On Jul 16, 2015, at 9:56 AM, Stephen Kent <kent@bbn.com<mailto:kent@bbn.com>> wrote:

Andy,

The context for the discussion is address space transfer in the RPKI context.
We don't have an RFC describing how to do that, AFAIK. So, when you say that
this is the scenario we have today, to what are you referring?

Steve

On Jul 15, 2015, at 4:41 PM, Stephen Kent <<mailto:kent@bbn.com>kent@bbn.com<mailto:kent@bbn.com>> wrote:

Randy's view is that it is preferable to engineer a single solution that is agnostic
about whether the address space is in use or not, even if that is a more complex
solution. His rationale seems to be that its safer to treat all space as in use, so as
to avoid the damage to users that arises if the entity transferring the space can't
properly classify it properly.

Isn’t the “unused” scenario what we have today? Why do we need a solution for something that is already being accomplished?

-andy


Steve,

Given what I said initially in this thread, I thought we were talking about the same thing. I guess not. We could tease this apart, but is it worth it if “Randy’s view” covers all situations?

-andy

v2.23.0 | Report a Bug | By Email