Re: [sig-policy] Address Transfer Policy Proposal
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, and
C: 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 fee
My 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 the
member 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.
Cheers
Terry