<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>RE: [arin-ppml] Policy Proposal 2008-6 - Staff Assessment</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>For completeness, I believe an additional distinction worthy of comment between 2008-6 and 2008-2 is that the trigger for implementation is at the discretion of the BoT in 2008-6 rather than being immediate.<BR>
<BR>
Bill Darte<BR>
ARIN AC and Author, 2008-6<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: arin-ppml-bounces@arin.net on behalf of Member Services<BR>
Sent: Wed 10/8/2008 3:22 PM<BR>
To: arin-ppml@arin.net<BR>
Subject: [arin-ppml] Policy Proposal 2008-6 - Staff Assessment<BR>
<BR>
Policy Proposal 2008-6<BR>
Title: Emergency Transfer Policy for IPv4 Addresses<BR>
Submitted: 15 August 2008<BR>
Assessment: 8 October 2008<BR>
<BR>
<BR>
ARIN Staff Assessment<BR>
<BR>
The assessment of this proposal includes comments from ARIN staff and<BR>
the ARIN General Counsel. It contains analysis of procedural, legal, and<BR>
resource concerns regarding the implementation of this policy proposal<BR>
as it is currently stated. Any changes to the language of the proposal<BR>
may necessitate further analysis by staff and Counsel.<BR>
<BR>
I. Proposal<BR>
<BR>
Policy Proposal is available below and at:<BR>
<A HREF="http://www.arin.net/policy/proposals/2008_6.html">http://www.arin.net/policy/proposals/2008_6.html</A><BR>
<BR>
II. Proposal Summary<BR>
<BR>
ARIN staff understands that this policy would create a second set of<BR>
transfer requirements when implemented. A resource holder deemed<BR>
legitimate by ARIN may transfer IPv4 addresses to a recipient that<BR>
qualifies for IPv4 addresses as long as the original block isn't broken<BR>
into more than four blocks.<BR>
<BR>
<BR>
III. Comments<BR>
<BR>
A. ARIN Staff<BR>
<BR>
1. The meaning of "without the active involvement of ARIN" in the first<BR>
sentence is unclear and should be further defined by the author.<BR>
<BR>
2. Section 1 indicates the transfer must be done by the "legitimate and<BR>
exclusive holder of those resources". The term "legitimate and exclusive<BR>
holder" is vague and must be clearly defined with accompanying criteria<BR>
to help staff determine who is eligible to transfer resources under this<BR>
policy.<BR>
<BR>
<BR>
3. Section 2 says that the recipient must have "documented operational<BR>
need in accordance with current ARIN policy". Current ARIN policies do<BR>
not allow the issuance of /23s and /24s with the exception of the<BR>
micro-allocation policy. This would indicate that no organization would<BR>
be allowed to transfer /23s and /24s under this policy unless they could<BR>
qualify under the micro-allocation policy which has very limited<BR>
eligibility.<BR>
<BR>
4. This policy would become 8.4 in the NRPM and not 8.2.1 as indicated.<BR>
<BR>
5. This policy proposal addresses the same subject matter as 2008-2.<BR>
They both specify requirements that Transferor and address space be<BR>
recognized by ARIN, Transferee demonstrate need and Transferee sign an<BR>
RSA. Additionally, they both include provisions on deaggregation,<BR>
minimum prefix size and directory services. They are distinguishable in<BR>
a number of other respects: for example, this policy would only be in<BR>
effect for three (3) years from its implementation, unlike 2008-2, and<BR>
it does not include specific criteria on matters such as facilitating<BR>
and establishing eligibility for the transfer. For a complete list of<BR>
differences, see comparison attached.<BR>
<BR>
<BR>
<BR>
B. ARIN General Counsel<BR>
<BR>
Counsel believes passage of an additional, more permissive transfer<BR>
policy would reduce potential legal risks and costs to ARIN arising from<BR>
transfer disputes as available IPv4 address space is depleted.<BR>
Specifically, counsel believes passage of 2008-2 or 2008-6 is better for<BR>
ARIN than continuing its current policy that is highly restrictive in<BR>
the right of parties to transfer number resources.<BR>
<BR>
We now turn to more specific concerns of this particular transfer policy.<BR>
<BR>
This policy is a major departure from existing ARIN policy which has<BR>
generally prohibited transfers except in specific, limited<BR>
circumstances. We therefore address the overall intent of the policy<BR>
from a legal perspective.<BR>
<BR>
The first legal concern in evaluating the specifics of any transfer<BR>
policy is whether it is consistent with antitrust law. Currently, this<BR>
policy does not create concerns. By creating a white market for transfer<BR>
of v4 resources, the policy arguably advances competition. In this<BR>
regard, there is no difference between 2008-2 and 2008-6.<BR>
<BR>
Second, any new policy should be consistent with the legal theory of the<BR>
Internet community that numbers are not "owned." We have no concerns<BR>
about the language of this proposal in this regard. In this regard,<BR>
there is no difference between 2008-2 and 2008-6.<BR>
<BR>
<BR>
No matter what transfer policy ARIN implements, it seems likely that<BR>
there will be more disputes, and hence more legal risk, once ARIN can no<BR>
longer satisfy requests for v4 resources. But if ARIN continues its<BR>
existing community created policy to prohibit most transfers, counsel<BR>
anticipates that widespread transfers in conflict with ARIN's current<BR>
policy would nonetheless occur - imposing significant future legal costs<BR>
including the costs of investigation, revocation, arbitration, and<BR>
litigation. A carefully drafted but more permissive transfer policy<BR>
would likely relieve ARIN of legal risks and cost. We therefore seek to<BR>
balance risks created by the community's adoption of the proposed policy<BR>
compared to the risks of retaining the current policy. This policy could<BR>
lead to future legal costs due to disputes arising from the lack of<BR>
specific criteria on transfer eligibility and other matters, which ARIN<BR>
staff would need to supply, and which would not have a community<BR>
consensus as a standards defense. Choosing between 2008-2 and 2008-6<BR>
should reflect the community evaluation of whether the additional issues<BR>
addressed in 2008-2 are correctly stated, or those issues are best left<BR>
to future policy development or staff interpretation. If a court were to<BR>
construe an application of 2008-6 if adopted, the court might find any<BR>
issue explicitly addressed in 2008-2 and not in 2008-6 cannot be applied<BR>
as interpretive policy.<BR>
<BR>
<BR>
IV. Resource Impact - Minimal<BR>
<BR>
The resource impact of implementing this policy is viewed as minimal.<BR>
Barring any unforeseen resource requirements, this policy could be<BR>
implemented within 90 days from the date of the ratification of the<BR>
policy by the ARIN Board of Trustees. It will require the following:<BR>
<BR>
· Updates to Guidelines will be required<BR>
· Staff training will be required<BR>
<BR>
Regards,<BR>
<BR>
Member Services<BR>
American Registry for Internet Numbers (ARIN)<BR>
<BR>
<BR>
#####<BR>
<BR>
<BR>
Policy Proposal 2008-6<BR>
Emergency Transfer Policy for IPv4 Addresses<BR>
<BR>
Author: Bill Darte<BR>
<BR>
Date: 26 August 2008<BR>
<BR>
Proposal type: New<BR>
<BR>
Policy term: Temporary<BR>
<BR>
Policy statement:<BR>
<BR>
8.2.1 Emergency Transfer Policy for IPv4 Addresses<BR>
<BR>
For a period of 3 years from policy implementation, transfer of ARIN<BR>
IPv4 addresses between two entities in the ARIN region, without the<BR>
active involvement of ARIN as an intermediary, will be considered<BR>
legitimate and will be documented accordingly under the following<BR>
conditions:<BR>
<BR>
1. Transfer takes place from a holder of IPv4 addresses recognized by<BR>
ARIN as the legitimate and exclusive holder of those resources.<BR>
<BR>
2. Transfer takes place to a recipient that has documented operational<BR>
need in accordance with current ARIN policy and that signs an RSA with<BR>
ARIN covering those resources in advance of transfer.<BR>
<BR>
3. Transfer of addresses takes place in such a way that the original<BR>
contiguous block(s) are not disaggregated into more than 4 resultant<BR>
network blocks each being greater than or equal to the current minimum<BR>
sizes specified in applicable ARIN policy.<BR>
<BR>
4. Transfer is complete and unrestricted and is supported by<BR>
documentation that ARIN deems satisfactory.<BR>
<BR>
Rationale:<BR>
<BR>
In order for ARIN to fulfill its mission and to facilitate a continuing<BR>
supply of IPv4 address resources to its service community when ARIN<BR>
resources are no longer adequate, and to preserve the integrity of<BR>
documentation and ARIN services for those resources, this policy may be<BR>
implemented. Its intent is to preserve the current tradition of<BR>
need-based allocation/assignments for those still needing IPv4 resources<BR>
during a transition period as the industry adopts IPv6. This policy is<BR>
not intended to create a 'market' for such transfers and does not<BR>
introduce or condone the monetization of address resources or a view of<BR>
addresses as property. It does recognize that organizations making<BR>
available unused or no longer needed address resources may incur certain<BR>
costs that might be compensated by those acquiring the resources. This<BR>
policy is intended to be transient and light-weight and does not<BR>
encourage a sustained or continuing role for IPv4, but rather helps to<BR>
mitigate a transitional crisis that may emerge while the industry adopts<BR>
IPv6 in accordance with the recommendation of ARIN's Board of Trustees.<BR>
<BR>
Timetable for implementation:<BR>
<BR>
This policy, once ratified by the ARIN Board of Trustees, would be<BR>
implemented when either the free-pool of IANA addresses is exhausted or<BR>
IPv4 address resources in the ARIN Region reaches a threshold of<BR>
scarcity recognized by the ARIN Board of Trustees as requiring this<BR>
policy implementation.<BR>
<BR>
#######################################################<BR>
<BR>
2008-6 and 2008-2 Compared<BR>
<BR>
<BR>
1. Issues Addressed in Both Policies:<BR>
<BR>
· Transferor and address space recognized by ARIN<BR>
<BR>
· Transferee demonstrates need<BR>
<BR>
· Transferee signs RSA<BR>
<BR>
· Deaggregation<BR>
<BR>
o 8-2: Unlimited<BR>
<BR>
o 8-6: Not more than 4 pieces (each greater than minimum prefix size)<BR>
<BR>
· Minimum prefix size<BR>
<BR>
o 8-2: /24<BR>
<BR>
o 8-6: Based on current policy.<BR>
<BR>
· Directory Services<BR>
<BR>
o WHOIS updated<BR>
<BR>
2. Policy Guidance is included in 2008-2, but not found in 2008-6:<BR>
<BR>
· Conditions on the transferor (source)<BR>
<BR>
o No outstanding balance<BR>
<BR>
o Has not received space from ARIN in preceding 12 months<BR>
<BR>
o If retains portion of space, must sign SA<BR>
<BR>
· Conditions on the transferee (recipient)<BR>
<BR>
o Intent to use space in ARIN service area<BR>
<BR>
o No outstanding balance<BR>
<BR>
o Not more than a 12-month supply<BR>
<BR>
o Not more often than once per 6 months<BR>
<BR>
· Safe harbor text<BR>
<BR>
o Availability for transfer does not give okay to ARIN to take it back.<BR>
<BR>
· Organizations under Common Ownership or Control<BR>
<BR>
o ARIN may consider this during requests.<BR>
<BR>
· Listing Service<BR>
<BR>
o Voluntary<BR>
<BR>
· Directory Services<BR>
<BR>
o Log of transfers<BR>
<BR>
<end><BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
PPML<BR>
You are receiving this message because you are subscribed to<BR>
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).<BR>
Unsubscribe or manage your mailing list subscription at:<BR>
<A HREF="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</A><BR>
Please contact info@arin.net if you experience any issues.<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>