<div dir="auto"><div>I support the motion as written.</div><div dir="auto">RD</div><div dir="auto"><br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On 21 Nov 2017 18:43,  <<a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send ARIN-PPML mailing list submissions to<br>
        <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:arin-ppml-owner@arin.net">arin-ppml-owner@arin.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of ARIN-PPML digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: Post-ARIN-40 updates to 2017-4 (Mike Burns)<br>
   2. Advisory Council Meeting Results - November 2017 (ARIN)<br>
   3. Draft Policy ARIN-2017-9: Clarification of Initial Block Size<br>
      for IPv4 ISP Transfers (ARIN)<br>
   4. Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4<br>
      Address Space (NRPM Section 4.2.1.6) (ARIN)<br>
   5. Draft Policy ARIN-2017-11: Reallocation and Reassignment<br>
      Language Cleanup (ARIN)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Fri, 17 Nov 2017 10:43:46 -0500<br>
From: "Mike Burns" <<a href="mailto:mike@iptrading.com">mike@iptrading.com</a>><br>
To: "'David Farmer'" <<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>>, "'Rob Seastrom'"<br>
        <<a href="mailto:rs-lists@seastrom.com">rs-lists@seastrom.com</a>><br>
Cc: <<a href="mailto:ppml@arin.net">ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] Post-ARIN-40 updates to 2017-4<br>
Message-ID: <004a01d35fba$db358570$<wbr>91a09050$@<a href="http://iptrading.com" rel="noreferrer" target="_blank">iptrading.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I support as written for the reasons David describes.<br>
<br>
<br>
<br>
<br>
<br>
From: ARIN-PPML [mailto:<a href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@<wbr>arin.net</a>] On Behalf Of David Farmer<br>
Sent: Friday, November 17, 2017 10:27 AM<br>
To: Rob Seastrom <<a href="mailto:rs-lists@seastrom.com">rs-lists@seastrom.com</a>><br>
Cc: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a> <<a href="mailto:ppml@arin.net">ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] Post-ARIN-40 updates to 2017-4<br>
<br>
<br>
<br>
I support this policy as written.<br>
<br>
<br>
<br>
The current reciprocity requirement does not recognize that the vast majority of IPv4 transfers are out of the ARIN region and the vast majority of the supply of IPv4 resources available for transfer exist within the ARIN region. Finally there are legitimate operational reasons that companies within the ARIN region need to transfer resources to themselves or their foreign subsidiaries in other regions regardless of reciprocal transfer policies being available.<br>
<br>
<br>
<br>
Thank you for simplifying the text.<br>
<br>
<br>
<br>
<br>
<br>
On Fri, Nov 17, 2017 at 7:12 AM, Rob Seastrom <<a href="mailto:rs-lists@seastrom.com">rs-lists@seastrom.com</a> <mailto:<a href="mailto:rs-lists@seastrom.com">rs-lists@seastrom.com</a>> > wrote:<br>
<br>
<br>
Dear Colleagues,<br>
<br>
Based on feedback received at the ARIN-40 conference, the AC Shepherds have updated Draft Policy 2017-4 - "Remove bidirectional requirement for inter-RIR transfers".<br>
<br>
The proposal in its entirety is below.  We seek feedback and comment.<br>
<br>
<br>
2017-4 - Remove bidirectional requirement for inter-RIR transfers<br>
<br>
Problem Statement:<br>
ARIN?s inter-RIR transfer policy is functionally one-way, so the assertion of a reciprocal two-way requirement is gratuitous.<br>
<br>
Policy statement:<br>
Add the following sentence after the first sentence of NRPM 8.4:<br>
Inter-RIR transfers may take place only via RIRs who agree to the transfer and share compatible, needs-based policies.<br>
<br>
Timetable for implementation: Immediate.<br>
<br>
<br>
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a> <mailto:<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>> ).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> <mailto:<a href="mailto:info@arin.net">info@arin.net</a>>  if you experience any issues.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
<br>
==============================<wbr>=================<br>
David Farmer               <a href="mailto:Email%3Afarmer@umn.edu">Email:farmer@umn.edu</a> <mailto:<a href="mailto:Email%253Afarmer@umn.edu">Email%3Afarmer@umn.edu</a><wbr>><br>
Networking & Telecommunication Services<br>
Office of Information Technology<br>
University of Minnesota<br>
2218 University Ave SE        Phone: <a href="tel:612-626-0815" value="+16126260815">612-626-0815</a><br>
Minneapolis, MN 55414-3029   Cell: <a href="tel:612-812-9952" value="+16128129952">612-812-9952</a><br>
==============================<wbr>=================<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.arin.net/pipermail/arin-ppml/attachments/20171117/b3cdc371/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.arin.net/<wbr>pipermail/arin-ppml/<wbr>attachments/20171117/b3cdc371/<wbr>attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 21 Nov 2017 17:37:31 -0500<br>
From: ARIN <<a href="mailto:info@arin.net">info@arin.net</a>><br>
To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
Subject: [arin-ppml] Advisory Council Meeting Results - November 2017<br>
Message-ID: <<a href="mailto:90ca93ea-ba77-0fc6-538d-c788ce02590f@arin.net">90ca93ea-ba77-0fc6-538d-<wbr>c788ce02590f@arin.net</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
In accordance with the Policy Development Process (PDP), the Advisory<br>
Council (AC) met on 16 November 2017.<br>
<br>
The AC has advanced the following Proposals to Draft Policy status (each<br>
will be posted for discussion):<br>
<br>
* ARIN-prop-244: Clarification of initial block size for IPv4 ISP transfers<br>
<br>
* ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM<br>
Section 4.2.1.6)<br>
<br>
* ARIN-prop-246: Reallocation and Reassignment Language Cleanup<br>
<br>
* ARIN-prop-247: Require New POC Validation Upon Reassignment<br>
<br>
* ARIN-prop-248: Remove ARIN Review Requirements for Large IPv4<br>
Reassignments/Reallocations<br>
<br>
The AC advances Proposals to Draft Policy status once they are found to<br>
be within the scope of the PDP, and contain a clear problem statement<br>
and suggested changes to Internet number resource policy text.<br>
<br>
The AC has sent the following to the Board of Trustees for adoption<br>
consideration:<br>
<br>
* Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration<br>
Requirements<br>
<br>
The AC provided the following statement:<br>
<br>
"After a successful conclusion of the Last Call period, the ARIN AC is<br>
forwarding Recommended Draft Policy ARIN-2017-5: Improved IPv6<br>
Registration Requirements to the ARIN Board with a request for adoption.<br>
Based on the consensus of the community at ARIN 40, the policy text was<br>
adjusted going into Last Call. While a minority dissent during Last Call<br>
period was in favor of the original text, the AC is of the view that the<br>
community thoroughly discussed that matter both at ARIN 40 and on PPML,<br>
and the consensus of the community supports the change in the text."<br>
<br>
The AC is continuing to work on:<br>
<br>
* ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation<br>
* ARIN-2017-4: Remove Bidirectional Requirement for Inter-RIR Transfers<br>
* ARIN-2017-8: Amend the Definition of Community Network<br>
<br>
The PDP can be found at:<br>
<a href="https://www.arin.net/policy/pdp.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/<wbr>pdp.html</a><br>
<br>
Draft Policies and Proposals under discussion can be found at:<br>
<a href="https://www.arin.net/policy/proposals/index.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/<wbr>proposals/index.html</a><br>
<br>
Regards,<br>
<br>
Sean Hopkins<br>
Policy Analyst<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 21 Nov 2017 17:40:39 -0500<br>
From: ARIN <<a href="mailto:info@arin.net">info@arin.net</a>><br>
To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of<br>
        Initial Block Size for IPv4 ISP Transfers<br>
Message-ID: <<a href="mailto:652abd11-68d7-900e-7776-b97b2311ea05@arin.net">652abd11-68d7-900e-7776-<wbr>b97b2311ea05@arin.net</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
On 16 November 2017, the ARIN Advisory Council (AC) advanced<br>
"ARIN-prop-244: Clarification of Initial Block Size for IPv4 ISP<br>
Transfers" to Draft Policy status.<br>
<br>
Draft Policy ARIN-2017-9 is below and can be found at:<br>
<a href="https://www.arin.net/policy/proposals/2017_9.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/<wbr>proposals/2017_9.html</a><br>
<br>
You are encouraged to discuss all Draft Policies on PPML. The AC will<br>
evaluate the discussion in order to assess the conformance of this draft<br>
policy with ARIN's Principles of Internet number resource policy as<br>
stated in the Policy Development Process (PDP). Specifically, these<br>
principles are:<br>
<br>
* Enabling Fair and Impartial Number Resource Administration<br>
* Technically Sound<br>
* Supported by the Community<br>
<br>
The PDP can be found at:<br>
<a href="https://www.arin.net/policy/pdp.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/<wbr>pdp.html</a><br>
<br>
Draft Policies and Proposals under discussion can be found at:<br>
<a href="https://www.arin.net/policy/proposals/index.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/<wbr>proposals/index.html</a><br>
<br>
Regards,<br>
<br>
Sean Hopkins<br>
Policy Analyst<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
<br>
Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4<br>
ISP Transfers<br>
<br>
Problem Statement:<br>
<br>
It was noted at the ARIN 40 Policy Experience Report, that there is an<br>
inconsistency in the initial block size for ISPs. Section 4.2.2 notes<br>
that the initial ISP block size should be /21 whereas the initial block<br>
size in 8.5.4 is noted as "minimum transfer size" which is effectively a<br>
/24. The intent of the new 8.5.4 was to match the previous policy. This<br>
policy is intended to clarify this issue. It was noted that ARIN staff<br>
current operational practice is to allow ISPs an initial /21 for Section<br>
8 transfers.<br>
<br>
Policy statement:<br>
<br>
Add the following to 8.5.4<br>
<br>
ISP organizations without direct assignments or allocations from ARIN<br>
qualify for an initial allocation of up to a /21.<br>
<br>
Comments:<br>
<br>
a. Timetable for implementation: Immediate<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 21 Nov 2017 17:42:02 -0500<br>
From: ARIN <<a href="mailto:info@arin.net">info@arin.net</a>><br>
To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
Subject: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate<br>
        Need for IPv4 Address Space (NRPM Section 4.2.1.6)<br>
Message-ID: <<a href="mailto:0ea280c3-adf7-1ee3-422f-5bd39b75a31c@arin.net">0ea280c3-adf7-1ee3-422f-<wbr>5bd39b75a31c@arin.net</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
On 16 November 2017, the ARIN Advisory Council (AC) advanced<br>
"ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM<br>
Section 4.2.1.6)" to Draft Policy status.<br>
<br>
Draft Policy ARIN-2017-10 is below and can be found at:<br>
<a href="https://www.arin.net/policy/proposals/2017_10.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/<wbr>proposals/2017_10.html</a><br>
<br>
You are encouraged to discuss all Draft Policies on PPML. The AC will<br>
evaluate the discussion in order to assess the conformance of this draft<br>
policy with ARIN's Principles of Internet number resource policy as<br>
stated in the Policy Development Process (PDP). Specifically, these<br>
principles are:<br>
<br>
* Enabling Fair and Impartial Number Resource Administration<br>
* Technically Sound<br>
* Supported by the Community<br>
<br>
The PDP can be found at:<br>
<a href="https://www.arin.net/policy/pdp.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/<wbr>pdp.html</a><br>
<br>
Draft Policies and Proposals under discussion can be found at:<br>
<a href="https://www.arin.net/policy/proposals/index.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/<wbr>proposals/index.html</a><br>
<br>
Regards,<br>
<br>
Sean Hopkins<br>
Policy Analyst<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
<br>
Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address<br>
Space (NRPM Section 4.2.1.6)<br>
<br>
Problem Statement:<br>
<br>
Section 4.2.1.6 of the ARIN Numbering Resource Policy Manual (NRPM)<br>
provides that an ISP having an immediate need for IPv4 address space<br>
that will be utilized within thirty days of a request may obtain a block<br>
of IPv4 address space of the size specified in section 4.2.1.6 from ARIN<br>
on an exceptional basis. However, as noted in the ARIN 40 Policy<br>
Experience Report, since IPv4 exhaustion, obtaining IPv4 addresses in<br>
this manner is no longer possible as a practical matter. Instead an ISP<br>
must join the waiting list and wait until it reaches the front of the<br>
queue to obtain any IPv4 address space, however long that may take. In<br>
effect, section 4.2.1.6 is non-operative. Accordingly, its continued<br>
presence in the NRPM is misleading and confusing.<br>
<br>
Policy statement:<br>
<br>
Section 4.2.1.6 of the NRPM is hereby repealed and section number<br>
4.2.1.6 is hereby retired.<br>
<br>
Comments:<br>
<br>
a. Timetable for implementation: Immediate<br>
<br>
b. Comments: Given the constraints created by the exhaustion of IPv4<br>
addresses, this proposal does not require any changes in the current<br>
ARIN practices for the allocation of IPv4 address space.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 21 Nov 2017 17:43:05 -0500<br>
From: ARIN <<a href="mailto:info@arin.net">info@arin.net</a>><br>
To: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
Subject: [arin-ppml] Draft Policy ARIN-2017-11: Reallocation and<br>
        Reassignment Language Cleanup<br>
Message-ID: <<a href="mailto:98d17d2f-c3f8-f395-77a2-6493f7d36452@arin.net">98d17d2f-c3f8-f395-77a2-<wbr>6493f7d36452@arin.net</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
On 16 November 2017, the ARIN Advisory Council (AC) advanced<br>
"ARIN-prop-246: Reallocation and Reassignment Language Cleanup" to Draft<br>
Policy status.<br>
<br>
Draft Policy ARIN-2017-11 is below and can be found at:<br>
<a href="https://www.arin.net/policy/proposals/2017_11.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/<wbr>proposals/2017_11.html</a><br>
<br>
You are encouraged to discuss all Draft Policies on PPML. The AC will<br>
evaluate the discussion in order to assess the conformance of this draft<br>
policy with ARIN's Principles of Internet number resource policy as<br>
stated in the Policy Development Process (PDP). Specifically, these<br>
principles are:<br>
<br>
* Enabling Fair and Impartial Number Resource Administration<br>
* Technically Sound<br>
* Supported by the Community<br>
<br>
The PDP can be found at:<br>
<a href="https://www.arin.net/policy/pdp.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/<wbr>pdp.html</a><br>
<br>
Draft Policies and Proposals under discussion can be found at:<br>
<a href="https://www.arin.net/policy/proposals/index.html" rel="noreferrer" target="_blank">https://www.arin.net/policy/<wbr>proposals/index.html</a><br>
<br>
Regards,<br>
<br>
Sean Hopkins<br>
Policy Analyst<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
<br>
Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup<br>
<br>
Problem Statement:<br>
<br>
The current text of NRPM uses the terms ?reallocate? and ?reassign? in<br>
ways that are both internally inconsistent within NRPM and inconsistent<br>
with the definitions of Reassignments and Reallocations as fields within<br>
the ARIN database. Frequently the term ?reassignment? or ?reassign? is<br>
used in NRPM as an umbrella term for both reallocations and<br>
reassignments. As a result, someone familiar with the ARIN Whois<br>
database, but unfamiliar with history of particular portions of NRPM and<br>
their intended meaning may interpret certain NRPM requirements as<br>
applying only to reassignments and not to reallocations. This is<br>
particularly problematic when it comes to SWIP requirements and the<br>
requirement to record reallocations and reassignments with ARIN, which<br>
under current text could be read to only apply to reassignments.<br>
<br>
Policy Statement:<br>
<br>
Make the following changes to the definitions in Section 2.5<br>
<br>
Current text:<br>
<br>
2.5. Allocate and Assign<br>
<br>
A distinction is made between address allocation and address assignment,<br>
i.e., ISPs are "allocated" address space as described herein, while<br>
end-users are "assigned" address space.<br>
<br>
Allocate - To allocate means to distribute address space to IRs for the<br>
purpose of subsequent distribution by them.<br>
<br>
Assign - To assign means to delegate address space to an ISP or<br>
end-user, for specific use within the Internet infrastructure they<br>
operate. Assignments must only be made for specific purposes documented<br>
by specific organizations and are not to be sub-assigned to other parties.<br>
<br>
Proposed Editorial Change:<br>
<br>
2.5 Allocation, Assignment, Reallocation, Reassignment<br>
<br>
Allocation - Address space delegated to an organization directly by ARIN<br>
for the purpose of subsequent distribution by the recipient organization<br>
to other parties.<br>
<br>
Assignment - Address space delegated to an organization directly by ARIN<br>
for the exclusive use of the recipient organization.<br>
<br>
Reallocation - Address space sub-delegated to an organization by an<br>
upstream provider for the purpose of subsequent distribution by the<br>
recipient organization to other parties.<br>
<br>
Reassignment - Address space  sub-delegated to an organization by an<br>
upstream provider for the exclusive use of the recipient organization.<br>
<br>
Make the following editorial changes to section 4.2:<br>
<br>
Current text:<br>
<br>
4.2.1.1. Purpose<br>
<br>
ARIN allocates blocks of IP addresses to ISPs for the purpose of<br>
reassigning that space to their customers.<br>
<br>
Proposed Editorial Change:<br>
<br>
4.2.1.1. Purpose<br>
<br>
ARIN allocates blocks of IP addresses to ISPs for the purpose of<br>
reassigning and reallocating that space to their customers.<br>
<br>
Current text:<br>
<br>
4.2.3. Reassigning Address Space to Customers<br>
<br>
Proposed Editorial Change:<br>
<br>
4.2.3. Reassigning and Reallocating Address Space to Customers<br>
<br>
Current Text:<br>
<br>
4.2.3.1. Efficient utilization<br>
<br>
ISPs are required to apply a utilization efficiency criterion in<br>
providing address space to their customers. To this end, ISPs should<br>
have documented justification available for each reassignment. ARIN may<br>
request this justification at any time. If justification is not<br>
provided, future receipt of allocations may be impacted.<br>
<br>
Proposed Editorial Change:<br>
<br>
4.2.3.1. Efficient utilization<br>
<br>
ISPs are required to apply a utilization efficiency criterion in<br>
providing address space to their customers. To this end, ISPs should<br>
have documented justification available for each reassignment and<br>
reallocation. ARIN may request this justification at any time. If<br>
justification is not provided, future receipt of allocations may be<br>
impacted.<br>
<br>
Current text:<br>
<br>
4.2.3.4. Downstream customer adherence<br>
<br>
ISPs must require their downstream customers to adhere to the following<br>
criteria:<br>
<br>
4.2.3.4.1. Utilization<br>
<br>
Reassignment information for prior allocations must show that each<br>
customer meets the 80% utilization criteria and must be available via<br>
SWIP / RWhois prior to your issuing them additional space.<br>
<br>
Proposed Editorial Changes:<br>
<br>
4.2.3.4. Downstream customer adherence<br>
<br>
ISPs must require their downstream customers to adhere to the following<br>
criteria:<br>
<br>
4.2.3.4.1. Utilization<br>
<br>
Reassignment and reallocation information for prior allocations must<br>
show that each customer meets the 80% utilization criteria and must be<br>
available via SWIP / RWhois prior to your issuing them additional space.<br>
<br>
Current text:<br>
<br>
4.2.3.5. ARIN approval of reassignments/reallocations<br>
<br>
4.2.3.5.1. /18<br>
<br>
All extra-large ISPs making reassignments of a /18 or larger to a<br>
customer must first have these reassignments reviewed and approved by ARIN.<br>
<br>
4.2.3.5.2. /19<br>
<br>
Small to large ISPs making customer reassignments of a /19 or larger<br>
must first seek ARIN's approval.<br>
<br>
Proposed Editorial Changes:<br>
<br>
4.2.3.5. ARIN approval of reassignments/reallocations<br>
<br>
4.2.3.5.1. /18<br>
<br>
All extra-large ISPs making reassignments or reallocations of a /18 or<br>
larger to a customer must first have these reassignments or<br>
reallocations reviewed and approved by ARIN.<br>
<br>
4.2.3.5.2. /19<br>
<br>
Small to large ISPs making customer reassignments or reallocations of a<br>
/19 or larger must first seek ARIN's approval.<br>
<br>
Current text:<br>
<br>
4.2.3.7.1. Reassignment Information<br>
<br>
Each IPv4 assignment containing a /29 or more addresses shall be<br>
registered in the WHOIS directory via SWIP or a distributed service<br>
which meets the standards set forth in section 3.2. Reassignment<br>
registrations shall include each client's organizational information,<br>
except where specifically exempted by this policy.<br>
<br>
Proposed Editorial Changes:<br>
<br>
4.2.3.7.1. Reassignment and Reallocation Information<br>
<br>
Each IPv4 reassignment or reallocation containing a /29 or more<br>
addresses shall be registered in the WHOIS directory via SWIP or a<br>
distributed service which meets the standards set forth in section 3.2.<br>
Reassignment and reallocation registrations shall include each client's<br>
organizational information, except where specifically exempted by this<br>
policy.<br>
<br>
Current text:<br>
<br>
4.2.3.7.2.Assignments visible within 7 days<br>
<br>
All assignments shall be made visible as required in section 4.2.3.7.1<br>
within seven calendar days of assignment.<br>
<br>
Proposed Editorial Changes:<br>
<br>
4.2.3.7.2.Reassignments and Reallocations visible within 7 days<br>
<br>
All reassignments and reallocations shall be made visible as required in<br>
section 4.2.3.7.1 within seven calendar days of reassignment or<br>
reallocation.<br>
<br>
Current text:<br>
<br>
4.2.4. ISP Additional Requests<br>
<br>
4.2.4.1. Utilization percentage (80%)<br>
<br>
ISPs must have efficiently utilized all allocations, in aggregate, to at<br>
least 80% and at least 50% of every allocation in order to receive<br>
additional space. This includes all space reassigned to their customers.<br>
<br>
Proposed Editorial Changes:<br>
<br>
4.2.4. ISP Additional Requests<br>
<br>
4.2.4.1. Utilization percentage (80%)<br>
<br>
ISPs must have efficiently utilized all allocations, in aggregate, to at<br>
least 80% and at least 50% of every allocation in order to receive<br>
additional space. This includes all space reassigned or reallocated to<br>
their customers.<br>
<br>
Make the following editorial changes to section 6 to clarify language<br>
regarding current practices and requirements for reallocations and<br>
reassignments, and specifically to clarify that recording reallocation<br>
information is required where current language is ambiguous:<br>
<br>
Current text:<br>
<br>
6.5.2.1(e) Initial Allocations to LIRs, Size<br>
<br>
For purposes of the calculation in (c), an LIR which has subordinate<br>
LIRs shall make such allocations according to the same policies and<br>
criteria as ARIN. In such a case, the prefixes necessary for such an<br>
allocation should be treated as fully utilized in determining the block<br>
sizing for the parent LIR. LIRs which do not receive resources directly<br>
from ARIN will not be able to make such allocations to subordinate LIRs<br>
and subordinate LIRs which need more than a /32 shall apply directly to<br>
ARIN.<br>
<br>
Proposed Editorial Changes:<br>
<br>
6.5.2.1(e) Initial Allocations to LIRs, Size<br>
<br>
For purposes of the calculation in (c), an LIR which has subordinate<br>
LIRs shall make such reallocations according to the same policies and<br>
criteria as ARIN. In such a case, the prefixes necessary for such a<br>
reallocation should be treated as fully utilized in determining the<br>
block sizing for the parent LIR. LIRs which do not receive resources<br>
directly from ARIN will not be able to make such reallocations to<br>
subordinate LIRs and subordinate LIRs which need more than a /32 shall<br>
apply directly to ARIN.<br>
<br>
Current text:<br>
<br>
6.5.2.2. Qualifications<br>
<br>
An organization qualifies for an allocation under this policy if they<br>
meet any of the following criteria:<br>
<br>
a. Have a previously justified IPv4 ISP allocation from ARIN or one of<br>
its predecessor registries or can qualify for an IPv4 ISP allocation<br>
under current criteria.<br>
<br>
b. Are currently multihomed for IPv6 or will immediately become<br>
multihomed for IPv6 using a valid assigned global AS number.<br>
<br>
In either case, they will be making reassignments from allocation(s)<br>
under this policy to other organizations.<br>
<br>
Provide ARIN a reasonable technical justification indicating why an<br>
allocation is necessary. Justification must include the intended<br>
purposes for the allocation and describe the network infrastructure the<br>
allocation will be used to support. Justification must also include a<br>
plan detailing anticipated assignments to other organizations or<br>
customers for one, two and five year periods, with a minimum of 50<br>
assignments within 5 years.<br>
<br>
Proposed Editorial Changes:<br>
<br>
6.5.2.2. Qualifications<br>
<br>
An organization qualifies for an allocation under this policy if they<br>
meet any of the following criteria:<br>
<br>
a. Have a previously justified IPv4 ISP allocation from ARIN or one of<br>
its predecessor registries or can qualify for an IPv4 ISP allocation<br>
under current criteria.<br>
<br>
b. Are currently multihomed for IPv6 or will immediately become<br>
multihomed for IPv6 using a valid assigned global AS number.<br>
<br>
In either case, they will be making reassignments or reallocations from<br>
allocation(s) under this policy to other organizations.<br>
<br>
Provide ARIN a reasonable technical justification indicating why an<br>
allocation is necessary. Justification must include the intended<br>
purposes for the allocation and describe the network infrastructure the<br>
allocation will be used to support. Justification must also include a<br>
plan detailing anticipated reassignments and reallocations to other<br>
organizations or customers for one, two and five year periods, with a<br>
minimum of 50 assignments within 5 years.<br>
<br>
Current text:<br>
<br>
6.5.4. Assignments from LIRs/ISPs<br>
<br>
Assignments to end users shall be governed by the same practices adopted<br>
by the community in section 6.5.8 except that the requirements in<br>
6.5.8.1 do not apply.<br>
<br>
Proposed Editorial Changes:<br>
<br>
6.5.4. Reassignments from LIRs/ISPs<br>
<br>
Reassignments to end users shall be governed by the same practices<br>
adopted by the community in section 6.5.8 except that the requirements<br>
in 6.5.8.1 do not apply.<br>
<br>
Current text:<br>
<br>
6.5.4.1. Assignment to operator's infrastructure<br>
<br>
An LIR may assign up to a /48 per PoP as well as up to an additional /48<br>
globally for its own infrastructure.<br>
<br>
Proposed Editorial Changes:<br>
<br>
6.5.4.1. Reassignment to operator's infrastructure<br>
<br>
An LIR may reassign up to a /48 per PoP as well as up to an additional<br>
/48 globally for its own infrastructure.<br>
<br>
Current text:<br>
<br>
6.5.5. Registration<br>
<br>
ISPs are required to demonstrate efficient use of IP address space<br>
allocations by providing appropriate documentation, including but not<br>
limited to assignment histories, showing their efficient use.<br>
<br>
Proposed Editorial Changes:<br>
<br>
6.5.5. Registration<br>
<br>
ISPs are required to demonstrate efficient use of IP address space<br>
allocations by providing appropriate documentation, including but not<br>
limited to reassignment and reallocation histories, showing their<br>
efficient use.<br>
<br>
Current text:<br>
<br>
6.5.5.1. Reassignment information<br>
<br>
Each static IPv6 assignment containing a /64 or more addresses shall be<br>
registered in the WHOIS directory via SWIP or a distributed service<br>
which meets the standards set forth in section 3.2. Reassignment<br>
registrations shall include each client's organizational information,<br>
except where specifically exempted by this policy.<br>
<br>
Proposed Editorial Changes:<br>
<br>
6.5.5.1. Reassignment information<br>
<br>
Each static IPv6 reassignment or reallocation containing a /64 or more<br>
addresses shall be registered in the WHOIS directory via SWIP or a<br>
distributed service which meets the standards set forth in section 3.2.<br>
Reassignment and reallocation registrations shall include each client's<br>
organizational information, except where specifically exempted by this<br>
policy.<br>
<br>
Current text:<br>
<br>
6.5.5.2. Assignments visible within 7 days<br>
<br>
All assignments shall be made visible as required in section 4.2.3.7.1<br>
within seven calendar days of assignment<br>
<br>
Proposed Editorial Changes:<br>
<br>
6.5.5.2. Reassignments and Reallocations visible within 7 days<br>
<br>
All reassignments and reallocations shall be made visible as required in<br>
section 4.2.3.7.1 within seven calendar days of reassignment or<br>
reallocation.<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
ARIN-PPML mailing list<br>
<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a><br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
<br>
------------------------------<br>
<br>
End of ARIN-PPML Digest, Vol 149, Issue 5<br>
******************************<wbr>***********<br>
</blockquote></div><br></div></div></div>