Re: [sig-policy] prop-096: Maintaining demonstrated needs requirement in
Hi Owen,
I'm one of proposers of prop-096, "Maintaining demonstrated needs
requirement in transfer policy after the final /8 phase". Thank you
for your support, and I'm so sorry for replying so late.
As you suggested, we basically think prop-096 is in set with prop-095,
"Inter-RIR IPv4 address transfer proposal". Please give us comments
if anyone think these proposals should be independent.
Yours Sincerely,
--
Tomohiro Fujisaki
From: Owen DeLong <owen at delong dot com>
Subject: Re: [sig-policy] prop-096: Maintaining demonstrated needs requirement in transfer policy after the final /8 phase
Date: Tue, 25 Jan 2011 03:13:47 -0800
| I strongly support this proposal. It rectifies an imbalance in policy that will
| prevent other RIRs from accepting global transfers to APNIC.
|
| Owen
|
|
| On Jan 25, 2011, at 2:30 AM, Terence Zhang YH wrote:
|
| > Dear SIG members,
| >
| > The proposal, 'Maintaining demonstrated needs requirement in transfer
| > policy after the final /8 phase', has been sent to the Policy SIG for
| > review. It will be presented at the Policy SIG at APNIC 31 in Hong Kong
| > SAR, China, 21-25 February 2011.
| >
| > We invite you to review and comment on the proposal on the mailing list
| > before the meeting.
| >
| > The comment period on the mailing list before an APNIC meeting is an
| > important part of the policy development process. We encourage you to
| > express your views on the proposal:
| >
| > - Do you support or oppose this proposal?
| > - Does this proposal solve a problem you are experiencing? If
| > so, tell the community about your situation.
| > - Do you see any disadvantages in this proposal?
| > - Is there anything in the proposal that is not clear?
| > - What changes could be made to this proposal to make it more
| > effective?
| >
| >
| > Information about this and other policy proposals is available from:
| >
| > http://www.apnic.net/policy/proposals
| >
| >
| > Gaurab, Ching-Heng, and Terence
| >
| >
| > _______________________________________________________________________
| >
| > prop-096-v001: Maintaining demonstrated needs requirement in transfer
| > policy after the final /8 phase
| > _______________________________________________________________________
| >
| > Author: Tomohiro Fujisaki
| >
| > Co-authors: Masaru Akai
| > Fuminori Tanizaki
| > Toshio Tachibana
| > Akira Nakagawa
| >
| > Version: 1
| >
| > Date: 25 January 2011
| >
| >
| >
| > 1. Introduction
| > ----------------
| >
| > This is a proposal to maintain the requirement for recipients of IPv4
| > transfers to justify their need for address space beyond the current
| > allocation phase and into the final /8 phase.
| >
| >
| > 2. Summary of the current problem
| > ----------------------------------
| >
| > The current APNIC transfer policy removes the requirement to
| > demonstrate a need for transferred IPv4 addresses after the final /8
| > phase begins.
| >
| > However, this removal of justification of need once APNIC enters the
| > final /8 phase will make APNIC the only RIR that does not require a
| > demonstrated need to be shown for an IPv4 transfer to be approved.
| >
| > If an inter-RIR transfer policy, such as prop-095, were to be approved,
| > given that any transfers would be conducted according to the transfer
| > policy of the source RIR, it would disadvantage APNIC if other RIRs
| > were to be able to transfer IPv4 addresses from APNIC without requiring
| > any justification.
| >
| > Contrast this with transfers where APNIC is the recipient of the
| > transfer, and must follow the transfer policy of the source RIR. Since
| > all other RIRs require justification in transfers, it would be more
| > difficult to have transfers of addresses into the APNIC region than it
| > would for addresses to be transferred out of the APNIC region.
| >
| > In addition, having no justification requirement in the final /8 phase
| > is raising concerns in some RIR regions and making them reluctant to
| > recognize any inter-RIR transfer policy with APNIC. Therefore, it is
| > possible that even if APNIC were to adopt prop-095, no other RIR may be
| > willing to engage in such inter-RIR transfers with APNIC.
| >
| >
| > 3. Situation in other RIRs
| > ---------------------------
| >
| > All other RIRs that adopt the IPv4 transfer policy require demonstrated
| > need at the time of the transfer.
| >
| > AfriNIC:
| >
| > AfriNIC permits transfers of IPv4 addresses as part of name changes
| > and transfers of tangible assets associated with addresses.
| > Utilization of the addresses must be verified. See Section 8.1,
| > "Introduction" in "IPv4 Address Allocation Policies":
| >
| > http://www.afrinic.net/docs/policies/AFPUB-2005-v4-001.htm
| >
| >
| > ARIN:
| >
| > ARIN policy requires that transfers to specified recipients can
| > take place provided the recipient can demonstrate the need for such
| > resources, as a single aggregate, in the exact amount which they
| > can justify under current ARIN policies. See Section 8.3,
| > "Transfers to Specified Recipients" in the "ARIN Number Resource
| > Policy Manual":
| >
| > https://www.arin.net/policy/nrpm.html#eight2
| >
| >
| > LACNIC:
| >
| > LACNIC policy has a transfer policy that will take effect when
| > LACNIC or any of its NIRs becomes unable, for the first time, to
| > cover an IPv4 block allocation or assignment because of a lack of
| > resources. Under this policy, the recipient of the transfer must be
| > able to justify its need for the IPv4 addresses. See Section
| > 2.3.2.18, "Transfer of IPv4 Blocks within the LACNIC Region," in
| > the LACNIC Policy Manual (v1.4):
| >
| > http://lacnic.net/en/politicas/manual3.html
| >
| >
| > RIPE:
| >
| > The RIPE policy permits transfers of complete or partial blocks of
| > IPv4 allocations. The RIPE NCC will evaluate the real need of the
| > receiving LIR as per the policies for further allocation. For more,
| > see section 5.5, "Transfers of Allocations", in "IPv4 Address
| > Allocation and Assignment Policies for the RIPE NCC Service Region:
| >
| > http://www.ripe.net/ripe/docs/ripe-509.html
| >
| >
| >
| > 4. Details
| > -----------
| >
| > It is proposed that recipients of transfers continue to be required to
| > justify their need for IPv4 address space after the final /8 policy is
| > activated.
| >
| >
| > 5. Pros/Cons
| > -------------
| >
| > Advantages:
| >
| > - It allows APNIC to maintain consistency with the pre-final /8
| > transfer policy and to observe its impact before any potential
| > future removal of the justification requirement.
| >
| > - It places APNIC policy in line with other RIRs on the transfer
| > conditions during APNIC's final /8 phase.
| >
| > - It will also prevent the APNIC region from having its address
| > space transferred to other regions without the recipient in the
| > other region needing to demonstrate a need for those addresses.
| >
| >
| > Disadvantages:
| >
| > - Some may argue that justifying need is an unecessary additional
| > requirement to the transfer of IPv4 addresses in the final /8
| > phase and could potentially be a barrier to the accurate
| > recording of transferred IPv4 blocks registered in the APNIC
| > Whois Database.
| >
| > However, if organizations have a genuine need for IPv4 addresses,
| > they should be able to explain and justify their requirements for
| > transfered IPv4 addresses, as they do before the final /8 phase
| > today.
| >
| >
| > 6. Effect on APNIC
| > -------------------
| >
| > This will change the condition of the transfer in the APNIC region in
| > the final /8 phase. However, since the criteria remains the same as
| > today, Members will actually not feel the impact.
| >
| >
| > 7. Effect on NIRs
| > ------------------
| >
| > It is the NIR's choice as to whether to adopt this policy.
| >
| > * 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
|
| * 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
|