Sandy,
On Jul 7, 2015, at 11:41 AM, Stephen Kent <[email protected]> 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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
