Keyboard Shortcuts
Thread View
j: Next unread messagek: Previous unread messagej a: Jump to all threadsj l: Jump to MailingList overview
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
geoff:
what about inter-region transfers? i heard a good idea that went along the lines of o the selling party must meet the criteria for sales in their region, and o the buyer must meed the criteria for buying in their region.
randy
Randy Bush wrote:
geoff:
what about inter-region transfers? i heard a good idea that went along the lines of o the selling party must meet the criteria for sales in their region, and o the buyer must meed the criteria for buying in their region.
randy
Right - many thanks for reminding me about that! Yes, I will add that to the proposal.
regards,
Geoff
[snip]
'Temporary' Transfers
[snip]
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.
I'm glad to see these changes. I mentioned my concerns (in Taipei) that the concept of a Registry sanctioned temporary transfer process, creates the assumption of liability or more correctly a duty of care to resolve a dispute when the inevitable happens and a transferee refuses to stopping announcing the route/s. Making the period/type of transfer entirely an issue between the parties is a good thing.
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.
Agree.
Geoff Huston
-- James
Geoff,
I agree with both suggestions, because
- Allowing block transfers of < /24 could encourage fragmentation of the routing table. And, as you say, we could remove this restriction later if it proved absolutely necessary.
- The fundamental operations of a database are record creations, modifications and deletions, and ensuring that only one record exists for each unique resource. I would argue that APNIC, as a registry, is essentially acting as a database of record using these simple operations, and if APNIC can retain that simplicity then the registry process for address transfers will be clear and robust, and will ensure confidence in APNIC.
Asking APNIC to manage lease timings for addresses would introduce significant process complexities and ambiguities beyond these basic registry functions, and place APNIC in the position of having to judge the actions and intentions of third parties. This could introduce risk to the reliability of APNIC's operations, and also could risk future confidence in APNIC's actions.
It would seem better (at least under current circumstances) to leave such timing matters to the realms of business contracts between the relevant parties, and leave APNIC to treat all transfers as basic registry actions, which implicitly have no timeframe associated with them - i.e. to treat any transfers as permanent, as you suggest.
Regards,
David
P.S. In your example, I assume you meant 10.128.0.0/9, rather than 10.1.0.0/9?
At 12:08 PM 11/06/2008, Geoff Huston wrote:
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' transfersHowever, 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 withdifferent 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 managementpolicy * _______________________________________________ sig-policy mailing list sig-policy@lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy
Activity Summary
- 5593 days inactive
- 5593 days old
- sig-policy@lists.apnic.net
- 4 participants
- 4 comments