IETF Logo Mail Archive

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

Stephen Kent <kent@bbn.com> Thu, 16 July 2015 13:56 UTC

Return-Path: <kent@bbn.com>
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 467BB1B3BF2 for <sidr@ietfa.amsl.com>; Thu, 16 Jul 2015 06:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 5eSCz54dIzlF for <sidr@ietfa.amsl.com>; Thu, 16 Jul 2015 06:56:41 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85CC1B3BB3 for <sidr@ietf.org>; Thu, 16 Jul 2015 06:56:41 -0700 (PDT)
Received: from ssh.bbn.com ([192.1.122.15]:53546 helo=COMSEC-2.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1ZFjeP-000PBc-CC; Thu, 16 Jul 2015 09:56:37 -0400
To: Andy Newton <andy@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>
From: Stephen Kent <kent@bbn.com>
Message-ID: <55A7B814.1020509@bbn.com>
Date: Thu, 16 Jul 2015 09:56:36 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1
MIME-Version: 1.0
In-Reply-To: <8BE719A0-0EC1-4E35-8BAD-A64E06D0979C@arin.net>
Content-Type: multipart/alternative; boundary="------------080209060600020208080307"
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/lZD1azMUiuYcGHnGztDdtCU0OXw>
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 13:56:44 -0000

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

v2.23.0 | Report a Bug | By Email