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

[Stephen Kent <[e-mail]>]

Sandy,

> On Jul 7, 2015, at 11:41 AM, Stephen Kent <[e-mail]> 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.
It's interesting that they make these distinctions, presumably for 
policy purposes.
> i don't find anything in their policy manual that says transfers are only for unused space.
I did not suggested that. What I said was that it seems likely that the 
growing number
of address space transfers will be for unused space, IF the reason for 
the transfer is a sale
of assets. (This seems to be the rationale cited for the growth in v4 
address space transfers.)
And, I noted that it seems attractive to engineer a solution to for 
unused space transfers
IF the solution is simpler than for live space transfers (it is), and IF 
unused space transfers
are the common case.

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.

Steve