Thanks, Rudi. That is very valuable feedback regarding the current situation in some parts of the ARIN region. <div><br></div><div>-Scott<span></span><br><br>On Friday, January 31, 2014, Rudolph Daniel <<a href="mailto:rudi.daniel@gmail.com">rudi.daniel@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Two networks connecting are not necessarily private peers.<br>
In the small Caribbean states, although there seems to be policy to implement IXP s, many are still not getting the buy in from existing ISP s ...so it is possible that an IXP could get off the ground with 2 and once up and running, others will join in.<br>
That could be a strategy.</p>
<p dir="ltr">So raising the bar to three minimum may well make it more difficult for them to get past the starting line. In my locale, we have 2 ISP s. And a planned IXP.<br>
My argument is that once we have an IXP, there is more of a likely hood that it will attract new providers, be it specialists like health or education for example.<br>
And since the number of networks connecting is not the only criteria for designating an IXP, my opinion is to leave it at two.</p>
<p dir="ltr">Rudi Daniel <br>
(information technologist)<br>
784 430 9235</p>
<div>On Jan 30, 2014 1:19 PM, <<a>arin-ppml-request@arin.net</a>> wrote:<br type="attribution"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="color:#777;font-size:12px;font-family:'Lucida Grande',Helvetica,Arial,sans-serif;padding:4px">
<a href="https://www.boxbe.com/overview" style="text-decoration:none;color:#5e96ea" target="_blank"><img alt="Boxbe" src="http://www.boxbe.com/images/logo_dark_small.png" width="64px" style="margin-left:0px;border:none"></a>
<img src="http://www.boxbe.com/stfopen?tc_serial=16233316801&tc_rand=178071754&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001">
This message is eligible for Automatic Cleanup! (<a>arin-ppml-request@arin.net</a>)
<a style="text-decoration:none;color:#5e96ea" href="https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Ftoken%3D%252B2Hpz4gnu%252FejMZuSFdv87bmQBOtxEDS3b9X7gpLdwNWGg8XULREXlQT0aw%252Bg4wvXefzxDae7hDB3aavY%252Fl%252BPimWlX2yI0NQXtOB1j063pJn2Hz8TkS%252BrWybaclKxn%252FQH2U8LmZNyew4wxDdpjPd28A%253D%253D%26key%3DpptuT0%252Fde44tGc8pS94PFdMgJuo2iA0z7G0HcQ%252BSG2c%253D&tc_serial=16233316801&tc_rand=178071754&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001" title="Add a new automatic cleanup rule" target="_blank">Add cleanup rule</a>
| <a style="text-decoration:none;color:#5e96ea" href="http://blog.boxbe.com/general/boxbe-automatic-cleanup?tc_serial=16233316801&tc_rand=178071754&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001" title="Get info on automatic cleanup" target="_blank">More info</a>
<br>
</div>
<br>Send ARIN-PPML mailing list submissions to<br>
<a>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" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a>arin-ppml-request@arin.net</a><br>
<br>
You can reach the person managing the list at<br>
<a>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. Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation<br>
Conservation Update (ARIN)<br>
2. Re: NRPM Policies 4.6 and 4.7 Suspended by ARIN Board (ARIN)<br>
3. Re: Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations<br>
(William Herrin)<br>
4. Re: Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip<br>
Language (William Herrin)<br>
5. Re: Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip<br>
Language (Bill Darte)<br>
6. Re: Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip<br>
Language (William Herrin)<br>
7. Re: Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip<br>
Language (David Huberman)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 29 Jan 2014 10:27:44 -0500<br>
From: ARIN <<a>info@arin.net</a>><br>
To: <a>arin-ppml@arin.net</a><br>
Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro<br>
Allocation Conservation Update<br>
Message-ID: <<a>52E91DF0.9040909@arin.net</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
On 24 January 2014 the ARIN Advisory Council (AC) accepted<br>
"ARIN-prop-200 Section 4.4 Micro Allocation Conservation Update" as a<br>
Draft Policy.<br>
<br>
Draft Policy ARIN-2014-7 is below and can be found at:<br>
<a href="https://www.arin.net/policy/proposals/2014_7.html" target="_blank">https://www.arin.net/policy/proposals/2014_7.html</a><br>
<br>
You are encouraged to discuss the merits and your concerns of Draft<br>
Policy 2014-7 on the Public Policy Mailing List.<br>
<br>
The AC will evaluate the discussion in order to assess the conformance<br>
of this draft policy with ARIN's Principles of Internet Number Resource<br>
Policy as stated in the PDP. Specifically, these principles are:<br>
<br>
* Enabling Fair and Impartial Number Resource Administration<br>
* Technically Sound<br>
* Supported by the Community<br>
<br>
The ARIN Policy Development Process (PDP) can be found at:<br>
<a href="https://www.arin.net/policy/pdp.html" target="_blank">https://www.arin.net/policy/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" target="_blank">https://www.arin.net/policy/proposals/index.html</a><br>
<br>
Regards,<br>
<br>
Communications and Member Services<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
## * ##<br>
<br>
<br>
Draft Policy ARIN-2014-7<br>
Section 4.4 Micro Allocation Conservation Update<br>
<br>
Date: 29 January 2014<br>
<br>
Problem Statement:<br>
<br>
Two networks interconnecting are private peers. Three could be<br>
considered an IXP. In light of exhaustion and the low reserve available<br>
to CI _and_ the significant growth of IXP's in North America, it is<br>
prudent to insure that there are minimum criteria that are sensible in<br>
order to not waste address space on an activity that is delineated by a<br>
minimum allocation vs. a /30. The barrier to entry remains low regardless.<br>
<br>
Policy statement:<br>
<br>
Change the following paragraph in Section 4.4 from:<br>
<br>
Exchange point operators must provide justification for the allocation,<br>
including: connection policy, location, other participants (minimum of<br>
two total), ASN, and contact information. ISPs and other organizations<br>
receiving these micro-allocations will be charged under the ISP fee<br>
schedule, while end-users will be charged under the fee schedule for<br>
end-users. This policy does not preclude exchange point operators from<br>
requesting address space under other policies.<br>
<br>
To:<br>
<br>
Exchange point operators must provide justification for the allocation,<br>
including: connection policy, location, other participants (minimum of<br>
three total), ASN, and contact information. IXP's formed as non profits<br>
will be considered end user organizations. All others will be considered<br>
ISPs.<br>
<br>
Comments:<br>
a.Timetable for implementation:<br>
b.Anything else:<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 29 Jan 2014 11:04:38 -0500<br>
From: ARIN <<a>info@arin.net</a>><br>
To: <a>arin-ppml@arin.net</a><br>
Subject: Re: [arin-ppml] NRPM Policies 4.6 and 4.7 Suspended by ARIN<br>
Board<br>
Message-ID: <<a>52E92696.4000709@arin.net</a>><br>
Content-Type: text/plain; charset=windows-1252; format=flowed<br>
<br>
> Per the PDP, the ARIN Advisory Council will review this matter and make a<br>
> recommendation to the Board. The AC's recommendation will be posted<br>
to the<br>
> Public Policy Mailing List for discussion.<br>
<br>
The ARIN Advisory Council recommended the following:<br>
<br>
"The Advisory Council supports the action of the Board to suspend<br>
sections 4.6 and 4.7 of the NRPM. The AC recommends the suspension<br>
remain in place while we work with the community on an appropriate<br>
policy response. To initiate community discussion, the AC submitted a<br>
proposal to remove Sections 4.6 and 4.7. The AC encourages input from<br>
the community on this matter. If anyone believes that aspects of the<br>
amnesty or aggregation policy should be retained, they are encouraged to<br>
post their comments and recommendations to the PPML.?<br>
<br>
Regards,<br>
<br>
Communications and Member Services<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
On 1/21/14 3:08 PM, ARIN wrote:<br>
> On 6 January 2014 the ARIN Board of Trustees, in accordance with the<br>
> ARIN Policy<br>
> Development Process (Part Two, Section 10.2 - Policy Suspension) suspended<br>
> Number Resource Policy Manual sections (NRPM) "4.6 Amnesty and Aggregation<br>
> Requests" and "4.7 Aggregation Requests".<br>
><br>
> From the Board's minutes: "The ARIN Board of Trustees suspends Sections<br>
> 4.6 and<br>
> 4.7 of the Number Resource Policy Manual, and refers the matter to the ARIN<br>
> Advisory Council per the Policy Development Process."<br>
><br>
> Per the PDP, the ARIN Advisory Council will review this matter and make a<br>
> recommendation to the Board. The AC's recommendation will be posted to the<br>
> Public Policy Mailing List for discussion.<br>
><br>
> The suspensions have been marked with notes from the editor in a new<br>
> version of<br>
> the policy manual- NRPM version 2014.2, dated 21 January 2014,<br>
> supersedes the<br>
> previous version.<br>
><br>
> Board minutes are available at: <a href="https://www.arin.net/about_us/bot/" target="_blank">https://www.arin.net/about_us/bot/</a><br>
><br>
> The ARIN Number Resource Policy Manual is available at:<br>
> <a href="https://www.arin.net/policy/nrpm.html" target="_blank">https://www.arin.net/policy/nrpm.html</a><br>
><br>
> The ARIN Policy Development Process is available at:<br>
> <a href="https://www.arin.net/policy/pdp.html" target="_blank">https://www.arin.net/policy/pdp.html</a><br>
><br>
> Regards,<br>
><br>
> Communications and Member Services<br>
> American Registry for Internet Numbers (ARIN)<br>
><br>
><br>
><br>
><br>
><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 29 Jan 2014 19:18:33 -0500<br>
From: William Herrin <<a>bill@herrin.us</a>><br>
Cc: "<a>arin-ppml@arin.net</a>" <<a>arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-5: Remove 7.2 Lame<br>
Delegations<br>
Message-ID:<br>
<CAP-guGXtXJ=wCi1PO2gxDapeCX1srLEm-L6=UYpk=<a>fb_5S_SmQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On Wed, Jan 29, 2014 at 10:27 AM, ARIN <<a>info@arin.net</a>> wrote:<br>
> On 24 January 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-197<br>
> Remove 7.2 Lame Delegations" as a Draft Policy.<br>
><br>
> ARIN will actively identify lame DNS name server(s) for reverse address<br>
> delegations associated with address blocks allocated, assigned or<br>
> administered by ARIN. Upon identification of a lame delegation, ARIN shall<br>
> attempt to contact the POC for that resource and resolve the issue. If,<br>
> following due diligence, ARIN is unable to resolve the lame delegation, ARIN<br>
> will update the Whois database records resulting in the removal of lame<br>
> servers.<br>
<br>
Howdy,<br>
<br>
Two decades of software improvements later, is there a *technical*<br>
need for ARIN to take any action at all with respect to lame<br>
delegations? Any stable DNS resolver has to deal with routine lame<br>
delegations in the forward DNS anyway.<br>
<br>
On a related note, does anyone actually make use of section 7.1,<br>
allowing an organization with less than a /16 to have ARIN handle all<br>
its RDNS rather than delegating it? How does that work? What are the<br>
mechanics involved in a registrant having ARIN set and change RDNS PTR<br>
records for him?<br>
<br>
I'm wondering if there's a good reason to keep any part of section 7 at all.<br>
<br>
Regards,<br>
Bill Herrin<br>
<br>
<br>
--<br>
William D. Herrin ................ <a>herrin@dirtside.com</a> <a>bill@herrin.us</a><br>
3005 Crane Dr. ...................... Web: <<a href="http://bill.herrin.us/" target="_blank">http://bill.herrin.us/</a>><br>
Falls Church, VA 22042-3004<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Wed, 29 Jan 2014 19:06:33 -0500<br>
From: William Herrin <<a>bill@herrin.us</a>><br>
To: ARIN <<a>info@arin.net</a>><br>
Cc: "<a>arin-ppml@arin.net</a>" <<a>arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-2: Improving 8.4<br>
Anti-Flip Language<br>
Message-ID:<br>
<<a>CAP-guGXmmkEHeorSO7hnDN9oO+RggTFsB7qO5KUjVjD0wOMDqQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On Wed, Jan 29, 2014 at 10:26 AM, ARIN <<a>info@arin.net</a>> wrote:<br>
> On 24 January 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-194<br>
> Improving 8.4 Anti-Flip Language" as a Draft Policy.<br>
><br>
> Modify 8.4:<br>
> Source entities within the ARIN region must not have received a transfer,<br>
> allocation, or assignment of IPv4 number resources from ARIN for the 12<br>
> months prior to the approval of a transfer request. This restriction does<br>
> not include M&A transfers. Restrictions related to recent receipt of blocks<br>
> shall not apply to inter-RIR transfers within the same organization and its<br>
> subsidiaries.<br>
<br>
Howdy.<br>
<br>
"and its subsidiaries" defeats the anti-flipping provision. Creating<br>
and then selling a "subsidiary" has a trivial cost. Restrict it to<br>
"same organization" and you won't have harmed things any more than<br>
having inter-rir transfers at all harms things.<br>
<br>
Regards,<br>
Bill Herrin<br>
<br>
<br>
<br>
--<br>
William D. Herrin ................ <a>herrin@dirtside.com</a> <a>bill@herrin.us</a><br>
3005 Crane Dr. ...................... Web: <<a href="http://bill.herrin.us/" target="_blank">http://bill.herrin.us/</a>><br>
Falls Church, VA 22042-3004<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Thu, 30 Jan 2014 06:11:27 -0600<br>
From: Bill Darte <<a>billdarte@gmail.com</a>><br>
To: William Herrin <<a>bill@herrin.us</a>><br>
Cc: "<a>arin-ppml@arin.net</a>" <<a>arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] Draft Policy ARIN-2014-2: Improving 8.4<br>
Anti-Flip Language<br>
Message-ID:<br>
<CAMApp35z+Cc+w+Kxt0P7XDDhb0qavy4nO=<a>jVCWh-1ue4P0rFZw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi Bill,<br>
<br>
Thanks for your input on this issue. We saw the same issue when adding the<br>
clause, but did so anyway to get insight from the community. Our reasoning<br>
was to get feedback on (at least) two issues....<br>
...first, the issue of organizational structure. What if an organization<br>
wishes to transfer to an 'existing' subsidiary....is that the same<br>
organization? Is it possible to allow subsidiary transfer, but bound it<br>
with a time constraint....'existing for the past XX months or years?<br>
...and, is this issue 'really' of concern given the late date relative to<br>
ARIN free-pool run out?<br>
<br>
Thanks again,<br>
bd<br>
<br>
<br>
<br>
<br>
On Wed, Jan 29, 2014 at 6:06 PM, William Herrin <<a>bill@herrin.us</a>> wrote:<br>
<br>
> On Wed, Jan 29, 2014 at 10:26 AM, ARIN <<a>info@arin.net</a>> wrote:<br>
> > On 24 January 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-194<br>
> > Improving 8.4 Anti-Flip Language" as a Draft Policy.<br>
> ><br>
> > Modify 8.4:<br>
> > Source entities within the ARIN region must not have received a transfer,<br>
> > allocation, or assignment of IPv4 number resources from ARIN for the 12<br>
> > months prior to the approval of a transfer request. This restriction does<br>
> > not include M&A transfers. Restrictions related to recent receipt of<br>
> blocks<br>
> > shall not apply to inter-RIR transfers within the same organization and<br>
> its<br></blockquote></div></blockquote></div><br><br>-- <br>Scott<br>