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

Sandra Murphy <sandy@tislabs.com> Wed, 08 July 2015 17:30 UTC

Return-Path: <sandy@tislabs.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 E21981A1B79 for <sidr@ietfa.amsl.com>; Wed, 8 Jul 2015 10:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.789
X-Spam-Level:
X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 30t204gmJ1il for <sidr@ietfa.amsl.com>; Wed, 8 Jul 2015 10:30:56 -0700 (PDT)
Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854FF1A1A62 for <sidr@ietf.org>; Wed, 8 Jul 2015 10:30:56 -0700 (PDT)
Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 70D6E28B0041; Wed, 8 Jul 2015 13:30:55 -0400 (EDT)
Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 617A81F8035; Wed, 8 Jul 2015 13:30:55 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_4EED9BAD-7A2B-4DA0-8D99-94304B870E2B"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Sandra Murphy <sandy@tislabs.com>
In-Reply-To: <559BF347.60609@bbn.com>
Date: Wed, 08 Jul 2015 13:30:54 -0400
Message-Id: <9DFC9C7C-CBFC-427C-8589-C13457EDD091@tislabs.com>
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>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1510)
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/rMhvCA25J2VmebaPTxpf76Aa8eY>
Cc: sidr wg list <sidr@ietf.org>, Sandra Murphy <sandy@tislabs.com>
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: Wed, 08 Jul 2015 17:30:59 -0000

On Jul 7, 2015, at 11:41 AM, Stephen Kent <kent@bbn.com> wrote:

> 
>>> - I think the doc should distinguish between transfers of "live"
>>>   address space vs. transfers of space that is not currently in
>>>   use. The former are more complex tan the latter and thus merit a
>>>   different discussion
>> operationally, you do not have a solid proof of [dis-]use.  and i do not
>> see how they should be treated differently.  prudence says do it as if it
>> is live.
> The TAO I-D describes the differences in constraints imposed on the
> transfer process based on live vs. unused space. Unused is much, much easier
> and seems to be the most common type of space transferred across RIR boundaries.
> Thus it seems worth considering the distinction in a discussion of the problem.


I wasn't looking for this, but I happened upon an APNIC page that describes transfer processes for three cases: unused space, for M&A, and for historical resources.  Answering their questions to get to the right case never got me to a page that is explicitly about transferring live address space.  M&A are likely to be live and historical could be live, I suppose.  i don't find anything in their policy manual that says transfers are only for unused space.

Here's the page about transfer in general:

https://www.apnic.net/services/become-a-member/manage-your-membership/transfer-resources

I think it would be interesting to hear from the RIR's as to whether they require resources to be unused, and for how long, before a transfer is possible.

That of course does not mean that transfers only occur between RIRs, or that we can always know whether address space is in use.

--Sandy, speaking as a regular ol' member

P.S.  From the APNIC site, here are some interesting flowcharts of the process:

Transfer of unused IPv4 and AS Numbers APNIC account holders (flowchart): https://cgi1.apnic.net/assets/apnic/js/apps/transfers/Transfer%20procedure%20of%20unused%20IPv4%20and%20AS%20Numbers%20between%20APNIC%20accounts.pdf

Transfer procedure of unused IPv4 from ARIN to APNIC accounts (flowchart): https://cgi1.apnic.net/assets/apnic/js/apps/transfers/Transfer%20procedure%20of%20unused%20IPv4%20from%20ARIN%20to%20APNIC%20accounts.pdf

detailed diagram for IPv4 transfer from other RIR to APNIC accounts:  https://www.apnic.net/services/become-a-member/manage-your-membership/transfer-resources/ARIN-to-APNIC-IPv4-Transfer-with-Fees.jpg