I was intending to make two substantive changes to the proposal
prior to the next meeting of the Policy SIG, namely:
- the removal of the minimum size of a /24
- additional text for 'temporary' transfers
However, I have concluded that neither change is really appropriate
at this point in time. My reasoning is below:
Removal of the /24 minimum transfer size
----------------------------------------
I have not seen in the consideration of this topic so far any
substantive argument that supports such a change at this point in
time, and the associated observation is that the routing system
still appears to implement a general prefix length filter at the /24 length.
If this changes in the future, and if there is a general view that
such a limitation of a /24 minimum size is no longer warranted, then
this restriction could be lifted by a subsequent policy action.
'Temporary' Transfers
---------------------
This refers to a concept similar to the "non-Permanent" transfer
proposed in RIPE, where the transfer is in effect for a limited
time, and that the transfer is "undone" at the expiration of the time period.
I started thinking about specific examples of chained transfers. For example:
1. A temporarily transfers 10.0.0.0/8 to B
2. B attempts to permanently transfer 10.0.0.0/16 to C
Who should be in a position to enforce the contradiction here?
And when C makes a temporary transfer of 10.0.0.0/24 to D with
different dates, who is responsible for tracking this?
Also consider:
1. A temporarily transfers 10.0.0.0/9 to C
2. B permanently transfers 10.1.0.0/9 to C
What are the constraints on C attempting to transfer 10.0.0.0/8 to D?
Who enforces such constraints?
Temporary, or timed, transfers place too high a burden on the
registry to enforce such constraints and there is a level of risk
about consistent and accurate enforcement of such non-permanent or
temporary transfers.
The alternative, which I would like to proceed with in terms of this
policy proposal, is for APNIC to treat ALL transfers as permanent
from the perspective of the registry function. It would then be a
matter for the two parties in the transfer to sort out via a
bilateral contract between the two parties if they:
- Agree that the transfer should be undone at some future date, and/or
- Agree that other constraints be placed on the transfer.
It's really no business of the registry to enforce these kinds of
caveats where the parties agree to some obligation or constraint.
Whether the registry should record the existence of such caveats in
the registry is a matter for future policy. Without any experience
or real understanding of such caveats and their potential
application it seems to be premature to start creating policies
regarding their registration at this point in time.
regards,
Geoff Huston
* sig-policy: APNIC SIG on resource management
policy *
_______________________________________________
sig-policy mailing list
sig-policy at lists dot apnic dot net
http://mailman.apnic.net/mailman/listinfo/sig-policy