Send ARIN-PPML mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Advisory Council Meeting Results - March 2013 (ARIN)
2. Recommended Draft Policy 2012-2: IPv6 Subsequent Allocations
Utilization Requirement (ARIN)
3. Recommended Draft Policy 2013-1: Section 8.4 Inter-RIR
Transfers of ASNs (ARIN)
----------------------------------------------------------------------
Message: 1
Date: Tue, 26 Mar 2013 16:09:05 -0400
From: ARIN <[email protected]>
To: [email protected]
Subject: [arin-ppml] Advisory Council Meeting Results - March 2013
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
In accordance with the ARIN Policy Development Process, the ARIN
Advisory Council (AC) held a meeting on 21 March 2013 and made decisions
about Proposals and Draft Policies.
Having found the following Draft Policies to be fully developed and
meeting ARIN's Principles of Internet Number Resource Policy, the AC
recommended them for adoption. They will be posted shortly for
discussion on the Public Policy Mailing List as Recommended Draft
Policies and they will be presented at ARIN 31. These drafts may go to
last call after ARIN 31:
ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement
ARIN-2013-1: Section 8.4 Inter-RIR Transfers of ASNs
The AC accepted the following Proposals as Draft Policies. They will be
posted separately to the Public Policy Mailing List. They are still
under development. They will be presented at ARIN 31, but will not be
eligible for last call:
ARIN-prop-184 3GPP Network IP Resource Policy
ARIN-prop-185 Tiny IPv6 Allocations for ISPs
Draft Policy and Proposal texts are available at:
https://www.arin.net/policy/proposals/index.html
The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html
Regards,
Communications and Member Services
American Registry for Internet Numbers (ARIN)
------------------------------
Message: 2
Date: Tue, 26 Mar 2013 16:11:40 -0400
From: ARIN <[email protected]>
To: [email protected]
Subject: [arin-ppml] Recommended Draft Policy 2012-2: IPv6 Subsequent
Allocations Utilization Requirement
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Recommended Draft Policy ARIN-2012-2
IPv6 Subsequent Allocations Utilization Requirement
On 21 March 2012 the ARIN Advisory Council (AC) recommended ARIN-2012-2
for adoption, making it a Recommended Draft Policy. ARIN-2012-2 will be
presented at ARIN 31, and will be eligible for last call afterward.
Draft Policy ARIN-2012-2 is below and can be found at:
https://www.arin.net/policy/proposals/2012_2.html
You are encouraged to discuss Draft Policy 2012-2 on the PPML prior to
the upcoming Public Policy Consultation. Both the discussion on the list
and at the meeting will be used by the ARIN Advisory Council to
determine the community consensus for adopting this as policy.
The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html
Regards,
Communications and Member Services
American Registry for Internet Numbers (ARIN)
## * ##
Recommended Draft Policy ARIN-2012-2
IPv6 Subsequent Allocations Utilization Requirement
Date: 26 March 2013
AC's assessment of conformance with the Principles of Internet Number
Resource Policy:
Policy 2012-2 enables fair and impartial resource administration by
creating an additional criteria under which LIRs can qualify for a
subsequent allocation. This policy does not modify the definition of who
is covered under the existing policy. This proposal addresses a
technical blindspot in the existing subsequent allocation policy that
limits initial IPv6 deployment growth. Over the last year, there has
been significant community support on the mailing list and at meetings
to rectify this blindspot. Coming to an agreement on specific wording
that does not open this to abuse has been more difficult.
Policy statement:
The change to the NRPM is the addition of the third bullet in 6.5.3.b.
2.14. Serving Site (IPv6) When applied to IPv6 policies, the term
serving site shall mean a location where an ISP terminates or aggregates
customer connections, including, but, not limited to Points of Presence
(POPs), Datacenters, Central or Local switching office or regional or
local combinations thereof.
6.5.3. Subsequent Allocations to LIRs
a. Where possible ARIN will make subsequent allocations by expanding the
existing allocation.
b. An LIR qualifies for a subsequent allocation if they meet any of the
following criteria:
* Shows utilization of 75% or more of their total address space
* Shows utilization of more than 90% of any serving site
* Has allocated more than 90% of their total address space to serving
sites, with the block size allocated to each serving site being
justified based on the criteria specified in section 6.5.2
c. If ARIN can not expand one or more existing allocations, ARIN shall
make a new allocation based on the initial allocation criteria above.
The LIR is encouraged, but not required to renumber into the new
allocation over time and return any allocations no longer in use.
d. If an LIR has already reached a /12 or more, ARIN will allocate a
single additional /12 rather than continue expanding nibble boundaries.
Rationale/Problem Statement:
Subnet expansion may occur rapidly and unevenly in the early stages of
IPv6 deployment. Providers may find that they have put all of their
subnets/serving sites into service, and do not have enough space to add
an additional serving site. They may have plenty of space available
within subnets to make customer assignments, but can not turn up a new
location (eg city, pop).
Timetable for implementation: Immediately
##########
ARIN Staff and Legal Assessment
ARIN Staff Assessment
ARIN-prop - 2012-2 ?Subsequent Allocations Utilization Requirement?
(Updated version)
Date of Assessment: 14 March 2013
1. Summary (Staff Understanding)
The intent of this proposal is to allow an additional way for ISP's that
have already begun using their IPv6 space but who may not have
sufficiently planned for longer term growth, to receive an additional
allocation. This policy would allow ISPs who have allocated at least
90% of their space to serving sites to qualify for an additional
allocation as long as the block size allocated to each serving site is
justified based on the number of customers at the largest single serving
site.
2. Comments
A. ARIN Staff Comments
? The updated text in 6.5.3b adds consistency and clarity to the policy
by allowing the block size for the subsequent allocation to be based on
the same criteria used to determine the block size for the initial
allocation.
? This policy is clear and implementable as written.
B. ARIN General Counsel - Legal Assessment
This policy does not create significant legal issues.
3. Resource Impact
This policy would have minimal resource impact from an implementation
aspect. It is estimated that implementation would occur within 3 months
after ratification by the ARIN Board of Trustees. The following would be
needed in order to implement:
A. Updated guidelines
B. Staff training
Proposal Text:
2.14. Serving Site (IPv6) When applied to IPv6 policies, the
term?serving site shall mean a location where an ISP terminates or
aggregates customer connections, including, but, not limited to Points
of Presence (POPs), Datacenters, Central or Local switching office or
regional or local combinations thereof.
6.5.3. Subsequent Allocations to LIRs
a. Where possible ARIN will make subsequent allocations by expanding the
existing allocation.
b. An LIR qualifies for a subsequent allocation if they meet any of the
following criteria:
? Shows utilization of 75% or more of their total address space
? Shows utilization of more than 90% of any serving site
? Has allocated more than 90% of their total address space to serving
sites, with the block size allocated to each serving site being
justified based on the criteria specified in section 6.5.2
c. If ARIN cannot expand one or more existing allocations, ARIN shall
make a new allocation based on the initial allocation criteria above.
The LIR is encouraged, but not required to renumber into the new
allocation over time and return any allocations no longer in use.
d. If an LIR has already reached a /12 or more, ARIN will allocate a
single additional /12 rather than continue expanding nibble boundaries.
Updated Rationale:
Subnet expansion may occur rapidly and un-evenly in the early stages of
IPv6 deployment. Providers may find that they have put all of their
subnets/serving sites into service, and do not have enough space to add
an additional serving site. They may have plenty of space available
within subnets to make customer assignments, but can not turn up a new
location (eg city, pop).
------------------------------
Message: 3
Date: Tue, 26 Mar 2013 16:12:40 -0400
From: ARIN <[email protected]>
To: [email protected]
Subject: [arin-ppml] Recommended Draft Policy 2013-1: Section 8.4
Inter-RIR Transfers of ASNs
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Recommended Draft Policy ARIN-2013-1
Section 8.4 Inter-RIR Transfers of ASNs
On 21 March 2012 the ARIN Advisory Council (AC) recommended ARIN-2013-1
for adoption, making it a Recommended Draft Policy. ARIN-2013-1 will be
presented at ARIN 31, and will be eligible for last call afterward.
Draft Policy ARIN-2013-1 is below and can be found at:
https://www.arin.net/policy/proposals/2013_1.html
You are encouraged to discuss Draft Policy 2013-1 on the PPML prior to
the upcoming Public Policy Consultation. Both the discussion on the list
and at the meeting will be used by the ARIN Advisory Council to
determine the community consensus for adopting this as policy.
The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html
Regards,
Communications and Member Services
American Registry for Internet Numbers (ARIN)
## * ##
Recommended Draft Policy ARIN-2013-1
Section 8.4 Inter-RIR Transfers of ASNs
Date: 26 Mar 2013
AC's assessment of conformance with the Principles of Internet Number
Resource Policy:
Draft policy 2013-1 enables fair and impartial resource administration,
supporting the goals of efficient utilization and accurate registration,
by allowing for the inter-RIR transfer of ASN resources under the same
guidelines already allowed for within-ARIN ASN transfers and inter-RIR
IPv4 number resource transfers. Discussion to date has identified
moderate support for the proposal. Most opposition to date has centered
on the argument that the proposal is unnecessary, but the AC shepherds
believe that it is worthwhile to allow transfers of ASNs, to help insure
that idle resources are both recovered and utilized efficiently and
where needed, and to allow the registry to be updated to reflect who is
actually using which ASNs.
Policy statement:
Modify the following text in Section 8.4
Add "or ASNs to be transferred, as" to the first bullet point under
Conditions on source of the transfer, so that it reads:
"The source entity must be the current rights holder of the IPv4 address
resources or ASNs to be transferred, as recognized by the RIR
responsible for the resources, and not be involved in any dispute as to
the status of those resources."
Change "IPv4 number resources" to "IPv4 number resources or ASNs", so
that the fourth bullet point reads:
"Source entities within the ARIN region must not have received a
transfer, allocation, or assignment of that same resource type (IPv4
number resource or ASN) from ARIN for the 12 months prior to the
approval of a transfer request. This restriction does not include M&A
transfers."
Rationale:
We already allow transfer of ASNs within the ARIN region. The change
will accomplish two things. First there is inconsistent language in 8.4
eg "IPv4 Address" v. "IPv4 Number Resource(s)" and second, it will allow
the transfer of ASNs between RIRs through 8.4 and using the standards we
have already established for IPv4 transfers. For many of the same
reasons that we allow transfer of IP addresses, we should allow
transfers of ASNs and to help insure that idle resources are both
recovered and utilized efficiently and where needed, and to allow the
registry to be updated to reflect who is actually using which ASNs.
This version clarifies that the 12-month restriction on having received
a transfer, allocation, or assignment applies separately to IPv4 number
resources and ASNs.
Timetable for implementation: Immediately
##########
ARIN Staff and Legal Assessment
ARIN Staff Assessment
ARIN-2013-1 ???Section 8.4 Inter-RIR Transfers of ASNs???
Date of Assessment: 19 Mar 2013
1. Summary (Staff Understanding)
This proposal would allow the transfer of ASNs along with IPv4 address
space in an 8.4 Inter-RIR transfer and applies all of the same criteria
currently listed for IPv4 to ASNs.
2. Comments
A. ARIN Staff Comments
The policy text reads: "Source entities within the ARIN region must not
have received a transfer, allocation, or assignment of IPv4 number
resources or ASNs from ARIN for the 12 months prior to the approval of a
transfer request."
??? As worded, the policy will prevent a party who has received a
transfer, allocation, or assignment of either an IPv4 block or an ASN
from transferring either one for a period of 12 months. In other words,
if an organization receives an ASN in the previous 12 months, this
policy text would prevent them from transferring their IPv4 addresses
via an 8.4 transfer. Was that the intent of the proposal?
??? If that is not the intent, we would suggest revising the text to
read something like this:
"Source entities within the ARIN region must not have received a
transfer, allocation, or assignment of that same resource type (IPv4
number resource or ASN) from ARIN for the 12 months prior to the
approval of a transfer request."
B. ARIN General Counsel - Legal Assessment
This proposal poses no significant legal issues.
3. Resource Impact
This policy would have minimal resource impact from an implementation
aspect. It is estimated that implementation would occur within 3 months
after ratification by the ARIN Board of Trustees. The following would be
needed in order to implement:
A. Updated guidelines
B. Staff training
Proposal Text:
ARIN-2013-1: Section 8.4 Inter-RIR Transfers of ASNs
Date: 8 March 2013
Policy statement:
Modify the following text in Section 8.4
Add "or ASNs to be transferred, as" to the first bullet point under
Conditions on source of the transfer, so that it reads:
"The source entity must be the current rights holder of the IPv4 address
resources or ASNs to be transferred, as recognized by the RIR
responsible for the resources, and not be involved in any dispute as to
the status of those resources."
Change "IPv4 number resources" to "IPv4 number resources or ASNs", so
that the fourth bullet point reads:
"Source entities within the ARIN region must not have received a
transfer, allocation, or assignment of IPv4 number resources or ASNs
from ARIN for the 12 months prior to the approval of a transfer request.
This restriction does not include M&A transfers."
Rationale:
We already allow transfer of ASNs within the ARIN region. The change
will accomplish two things. First there is inconsistent language in 8.4
eg "IPv4 Address" v. "IPv4 Number Resource(s)" and second, it will allow
the transfer of ASNs between RIRs through 8.4 and using the standards we
have already established for IPv4 transfers. For many of the same
reasons that we allow transfer of IP addresses, we should allow
transfers of ASNs and to help insure that idle resources are both
recovered and utilized efficiently and where needed, and to allow the
registry to be updated to reflect who is actually using which ASNs.
This version changes the title, clarifies the resulting policy language
slightly, and explicitly includes the resulting policy language in the
policy statement.
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 93, Issue 12
*****************************************
