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