Hi Geoff, On 03/06/2009, at 5:33 PM, Geoff Huston wrote:
A: addresses held by current financial members of APNIC,B: addresses held by non-members of APNIC who pay APNIC a non-member service fee associated with the address holding, andC: there are "historical" address resources which are listed in the APNIC databases and the listed holder is not a financial member and the address is not the subject of an annual maintenance feeMy intent was to say that addresses in categories A and B are "current" addresses and may be transferred, and category C addresses are not eligible to be transferred. In the later case the entity concerned can become a member or reestablish a relationship with APNIC and pay an annual maintenance fee and then the addresses are eligible for transfer.
That sounds onerous (cost wise) on an organisation that 1) holds historical addresses, 2) wishes to pass them to another entity for valid use.
The reason why I felt that this was appropriate is that addresses in category C may, or may not, have a clear and current record of the current holder of the address resource and the process of making the addresses current within APNIC's existing processes uses a set of procedures that
I think this represents a level of uncertainty if those "C" addresses cannot be sensibly brought into the framework rapidly through a suitable process or there is some doubt as to the current holder. Such that category C resources left out there may exist and foster some black market which is untraceable and leaves the registry with holes. Something to try to avoid perhaps.
I would urge the secretariat to confirm that all those category C allocations are demonstrably with those organisations and APNIC can confirm that the registry is sane before committing to a larger transfer policy. That may be costly to the secretariat, but of a larger significant benefit to the community.
call on the holder to demonstrate their continuing association with the addresses - it was hoped that this would improve, to some extent, the integrity of transfer transactions in so far as the intent was that transfer transactions would be registered when both parties were "known" to APNIC, and APNIC would avoid becoming a party to possibly fraudulent transfer transactions.For NIRs, similar considerations would apply, I assume.If there are better ways to phrase this in terms of a policy statement I would appreciate assistance in terms of appropriate terminology. Perhaps some advice from the Policy folk in the Secretariat?
Given that there is no time constraint stated here then the intent was to allow an NIR the choice of adopting this policy or not.
hrmmm.. while RIR governance is not a stick and national bodies may follow the desires of the their members, that statement leaves me cold. And while I would love the transfer policy to be in place for "the greater good" throughout the region I can foresee that if any NIR abstains from implementing the policy - they would be inadvertently erecting barriers and creating borders on the non-geographical nature of the internet.
I would assume that the NIR communities would be aware that that the short term industry needs following the exhaustion of the unallocated IPv4 pools would imply that such a policy has greater benefit in terms of ensuring continuing accuracy and relevance of the registry system and in continuing some level of distribution of addresses if such a policy was adopted earlier rather than later, but I understand that the NIRs were desirous of having the ability to adopt such a policy within timing parameters as determined by their national community.
I certainly hope it is only timing. The differences expressed between JPNICs members and that of the JPNIC secretariat were sobering.
- when a member disposes of address space using this transfer policy themember should not be entitled to any further IPv4 allocations or assigments from APNIC for an extended period (two years?)or until the final /8 is reached.My intent with this two year period constraint was to cover a number of possible eventualities, including APNIC performing subsequent allocations from returned address space even after after the final / 8 has been invoked.
For larger, more stable businesses that may be a suitable approach. For developing businesses in developing countries I would err on the side of flexibility.
Thank you for this suggestion.Do others feel similarly? And, conversely, are there other who are of the opinion that this is perhaps a imposing too onerous a constraint on the registration of a transfer transaction?I'd like to point out that the reason why such a constraint, and why other similar conditions or
I don't see it as a constraint.. you are not limiting the transfer by _also_ providing IPv6 addresses at the same time. It is recognition that an organisation clearly needs addresses, surely the preference would be to encourage v6 use? Perhaps asking for a "plan" might be too much.
"I see you have acquired more v4! we also notice that you currently don't have any v6. Here a suitable v6 allocation as well to help you along".
..Perhaps going that extra step is evolutionary..
constraints were not included into the original address transfer policy proposal was that it is my personal view that the registry system has remarkably little enforcement mechanism when the associated allocation function has concluded. The way I have phrased this in the past is that if the constraints on registration of an address transfer in APNIC's registry was too onerous, then the most likely outcome is that other forms of registration would appear and that the risk of creating unwanted and dangerous chaos in address uniqueness would be considerably greater. I felt that there needed to be a balance between ensuring that the registry was able to continue to operate in a manner that was accessible and free of onerous constraints and imposing a number of somewhat extraneous constraints and conditions that are superfluous to the basic registry function.
Oh, you mean a constraint on APNIC "the secretariat"? Surely automated tools would maintain the registry consistency and be a minimal resource concern for adjudicating transfers?
Maybe I'm thinking beyond the secretariat's capabilities.
I wrote up some thoughts on this topic at http://www.potaroo.net/ispcol/2008-11/transfers.html that you may find useful in thinking about the various issues that may be at play here.
I'll be sure to read those writings.
If there is a broad feeling from this community that such additional constraints and conditions relating to the disclosure to APNIC of some form of IPv6 deployment plan should accompany a registration transfer request, then that certainly can be added to the proposal.
At this juncture in the evolution of the internet I'm heading toward the camp that v4_need == v6_need. If you transfer in v4 resources, you probably should also have some v6.