In support of 2014-21...Yes, and more ixp s on the horizon, the countries in Caribbean region within Arin are also still in the creation stage of suitable CI.
Rudi Daniel ICT consulting & lighting products 784 430 9235 On Dec 2, 2014 1:44 PM, <[email protected]> wrote: > 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. Re: 2014:21.CI pool size (Karl Brumund) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Dec 2014 12:42:58 -0500 > From: Karl Brumund <[email protected]> > To: "[email protected]" <[email protected]> > Subject: Re: [arin-ppml] 2014:21.CI pool size > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > As the Internet continues to grow, the amount of critical infrastructure > within the Internet also continues to grow. While the ARIN region is more > mature than other regions, we are still seeing this growth increase. > For these reasons, we support increasing the CI pool size. > > > ?karl > > Principal Engineer > Dyn > > > > On Dec 2, 2014, at 10:57 AM, Steven Ryerse <[email protected]> > wrote: > > > > I support this as well. > > > > Steven Ryerse > > President > > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > > 770.656.1460 - Cell > > 770.399.9099- Office > > > > <image001.jpg>? Eclipse Networks, Inc. > > Conquering Complex Networks? > > > > From: [email protected] [mailto:[email protected]] On > Behalf Of Rudolph Daniel > > Sent: Tuesday, December 2, 2014 7:03 AM > > To: [email protected] > > Subject: Re: [arin-ppml] 2014:21.CI pool size > > > > I Support this CI pool size increase. > > > > Rudi Daniel > > 784 430 9235 > > > > On Dec 1, 2014 8:09 PM, <[email protected] <mailto: > [email protected]>> wrote: > > Send ARIN-PPML mailing list submissions to > > [email protected] <mailto:[email protected]> > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://lists.arin.net/mailman/listinfo/arin-ppml < > http://lists.arin.net/mailman/listinfo/arin-ppml> > > or, via email, send a message with subject or body 'help' to > > [email protected] <mailto:[email protected]> > > > > You can reach the person managing the list at > > [email protected] <mailto:[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 - November 2014 (ARIN) > > 2. Draft Policy ARIN-2014-21: Modification to CI Pool Size per > > Section 4.4 (ARIN) > > 3. Draft Policy ARIN-2014-22: Removal of Minimum in Section 4.10 > > (ARIN) > > 4. Weekly posting summary for [email protected] <mailto:[email protected]> > (Thomas Narten) > > 5. Re: Multi-homing justification removed? (Owen DeLong) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 25 Nov 2014 15:34:58 -0500 > > From: ARIN <[email protected] <mailto:[email protected]>> > > To: [email protected] <mailto:[email protected]> > > Subject: [arin-ppml] Advisory Council Meeting Results - November 2014 > > Message-ID: <[email protected] <mailto:[email protected]>> > > Content-Type: text/plain; charset=gbk; format=flowed > > > > In accordance with the ARIN Policy Development Process (PDP), the ARIN > > Advisory Council (AC) met on 20 November 2014. > > > > The AC recommended the following to the ARIN Board for adoption: > > > > Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA > > and 8.2 Utilization Requirements > > > > The AC accepted the following Proposals as a Draft Policies: > > > > ARIN-prop-213 Modification to CI Pool Size per Section 4.4 > > ARIN-prop-214 Removal of Minimum in Section 4.10 > > > > The AC is continuing to work on the following: > > > > Draft Policy ARIN-2014-1: Out of Region Use > > Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs] > > Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 > Transfers > > Draft Policy ARIN-2014-17: Change Utilization Requirements from > > last-allocation to total-aggregate > > Draft Policy ARIN-2014-19: New MDN Allocation Based on Past > Utilization > > > > Draft Policy and Proposal texts are available at: > > https://www.arin.net/policy/proposals/index.html < > https://www.arin.net/policy/proposals/index.html> > > > > The ARIN Policy Development Process can be found at: > > https://www.arin.net/policy/pdp.html < > https://www.arin.net/policy/pdp.html> > > > > Regards, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 25 Nov 2014 15:35:15 -0500 > > From: ARIN <[email protected] <mailto:[email protected]>> > > To: [email protected] <mailto:[email protected]> > > Subject: [arin-ppml] Draft Policy ARIN-2014-21: Modification to CI > > Pool Size per Section 4.4 > > Message-ID: <[email protected] <mailto:[email protected] > >> > > Content-Type: text/plain; charset=gbk; format=flowed > > > > On 20 November 2014 the ARIN Advisory Council (AC) accepted > > "ARIN-prop-213 Modification to CI Pool Size per Section 4.4" as a Draft > > Policy. > > > > Draft Policy ARIN-2014-21 is below and can be found at: > > https://www.arin.net/policy/proposals/2014_21.html < > https://www.arin.net/policy/proposals/2014_21.html> > > > > You are encouraged to discuss the merits and your concerns of Draft > > Policy 2014-21 on the Public Policy Mailing List. > > > > The AC will evaluate the discussion in order to assess the conformance > > of this draft policy with ARIN's Principles of Internet Number Resource > > Policy as stated in the PDP. Specifically, these principles are: > > > > * Enabling Fair and Impartial Number Resource Administration > > * Technically Sound > > * Supported by the Community > > > > The ARIN Policy Development Process (PDP) can be found at: > > https://www.arin.net/policy/pdp.html < > 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 < > https://www.arin.net/policy/proposals/index.html> > > > > Regards, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Draft Policy ARIN-2014-21 > > Modification to CI Pool Size per Section 4.4 > > > > Date: 25 November 2014 > > > > Problem Statement: > > > > At the time that this section of policy was written, IXP growth in North > > America was stagnant. Efforts of late have increased significantly > > within the IXP standards and other communities to improve critical > > infrastructure in North America. This effort is paying dividends and we > > project that a /16 will not be enough to continue to improve global > > interconnect conditions and support needed IXP CI infrastructure. > > > > Policy statement: > > > > Change to text in section 4.4 Micro Allocations: > > > > Current text: > > > > ARIN will place an equivalent of a /16 of IPv4 address space in a > > reserve for Critical Infrastructure, as defined in section 4.4. If at > > the end of the policy term there is unused address space remaining in > > this pool, ARIN staff is authorized to utilize this space in a manner > > consistent with community expectations. > > > > Proposed text to replace current text entirely: > > > > ARIN will place an equivalent of a /15 of IPv4 address space in a > > reserve for Critical Infrastructure, as defined in section 4.4. > > > > Timetable for implementation: Immediate > > > > > > ------------------------------ > > > > Message: 3 > > Date: Tue, 25 Nov 2014 15:35:29 -0500 > > From: ARIN <[email protected] <mailto:[email protected]>> > > To: [email protected] <mailto:[email protected]> > > Subject: [arin-ppml] Draft Policy ARIN-2014-22: Removal of Minimum in > > Section 4.10 > > Message-ID: <[email protected] <mailto:[email protected]>> > > Content-Type: text/plain; charset=gbk; format=flowed > > > > On 20 November 2014 the ARIN Advisory Council (AC) accepted > > "ARIN-prop-214 Removal of Minimum in Section 4.10" as a Draft Policy. > > > > Draft Policy ARIN-2014-22 is below and can be found at: > > https://www.arin.net/policy/proposals/2014_22.html < > https://www.arin.net/policy/proposals/2014_22.html> > > > > You are encouraged to discuss the merits and your concerns of Draft > > Policy 2014-22 on the Public Policy Mailing List. > > > > The AC will evaluate the discussion in order to assess the conformance > > of this draft policy with ARIN's Principles of Internet Number Resource > > Policy as stated in the PDP. Specifically, these principles are: > > > > * Enabling Fair and Impartial Number Resource Administration > > * Technically Sound > > * Supported by the Community > > > > The ARIN Policy Development Process (PDP) can be found at: > > https://www.arin.net/policy/pdp.html < > 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 < > https://www.arin.net/policy/proposals/index.html> > > > > Regards, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Draft Policy ARIN-2014-22 > > Removal of Minimum in Section 4.10 > > > > Date: 25 November 2014 > > > > Problem Statement: > > > > The current section 4.10 Dedicated IPv4 block to facilitate IPv6 > > Deployment creates an issue where a small new organization that requires > > an IPv4 allocation or assignment would potentially receive a block that > > today would be unroutable and therefore unusable for it intended > purposes. > > > > Policy statement: > > > > Change > > > > "This block will be subject to a minimum size allocation of /28 and a > > maximum size allocation of /24. ARIN should use sparse allocation when > > possible within that /10 block." > > > > To > > > > "This block will be subject to an allocation of /24. ARIN should use > > sparse allocation when possible within that /10 block." > > > > Timetable for implementation: Immediate > > > > > > ------------------------------ > > > > Message: 4 > > Date: Fri, 28 Nov 2014 00:53:04 -0500 > > From: Thomas Narten <[email protected] <mailto:[email protected]>> > > To: [email protected] <mailto:[email protected]> > > Subject: [arin-ppml] Weekly posting summary for [email protected] <mailto: > [email protected]> > > Message-ID: <[email protected] <mailto: > [email protected]>> > > Content-Type: text/plain; charset=us-ascii > > > > Total of 5 messages in the last 7 days. > > > > script run at: Fri Nov 28 00:53:03 EST 2014 > > > > Messages | Bytes | Who > > --------+------+--------+----------+------------------------ > > 60.00% | 3 | 55.51% | 18354 | [email protected] <mailto:[email protected] > > > > 20.00% | 1 | 22.60% | 7473 | [email protected] <mailto: > [email protected]> > > 20.00% | 1 | 21.89% | 7240 | [email protected] <mailto: > [email protected]> > > --------+------+--------+----------+------------------------ > > 100.00% | 5 |100.00% | 33067 | Total > > > > > > > > ------------------------------ > > > > Message: 5 > > Date: Mon, 1 Dec 2014 16:04:21 -0800 > > From: Owen DeLong <[email protected] <mailto:[email protected]>> > > To: Scott Leibrand <[email protected] <mailto: > [email protected]>> > > Cc: "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>> > > Subject: Re: [arin-ppml] Multi-homing justification removed? > > Message-ID: <[email protected] <mailto: > [email protected]>> > > Content-Type: text/plain; charset="utf-8" > > > > FWIW, Scott, your interpretation agrees with my recollection and my > intents along the way. > > > > I am not convinced that such a policy applied to the transfer market is > a good idea. I believe that portable blocks place sufficient demand on > internet resources that having a some number of hosts behind them (50%+) is > not an unreasonable requirement regardless of whether the block is freshly > minted from the RIR or recycled. > > > > Owen > > > > > On Nov 20, 2014, at 9:42 AM, Scott Leibrand <[email protected] > <mailto:[email protected]>> wrote: > > > > > > Steve, > > > > > > I think your interpretation of 4.3.2.2 is incorrect. That policy > section was not the one that authorized the receipt of a (PA) /24 for > multihoming. That was, and still is, 4.2.3.6 <http://4.2.3.6/ < > http://4.2.3.6/>>: > > > https://www.arin.net/policy/nrpm.html#four236 < > https://www.arin.net/policy/nrpm.html#four236> < > https://www.arin.net/policy/nrpm.html#four236 < > https://www.arin.net/policy/nrpm.html#four236>>, which states that "The > ISP will then verify the customer's multihoming requirement and may assign > the customer a /24, based on this policy." > > > > > > 4.3.2.2 states that the minimum allocation size (from ARIN) for > multihomed end users was a /24. However, that did not allow you to get a > /24 from ARIN just by becoming multihomed. If you were/are in that > situation, you always had to (and still have to) get your /24 from your > upstream if you don't meet ARIN's /24 utilizatinon criteria, and > demonstrate efficient utilization before getting one from ARIN. > > > > > > If my understanding does not match how policy was implemented by staff > prior to implementation of ARIN-2014-13 on 17 September 2014, someone > please correct me, but that was the intent of the policy as I understand it. > > > > > > When discussing 2014-13, my sense of the community was that we did not > want to authorize receipt of a /24 from ARIN solely based on multihoming, > because that could possibly open up a land rush of organizations spun up > solely for the purpose of getting a /24 from the free pool, holding it for > the requisite time, and then selling it on the transfer market. I > personally would be more amenable to considering a policy change to > liberalize the requirements for getting a /24 if/when they're available > from the transfer market only. > > > > > > -Scott > > > > > > On Thu, Nov 20, 2014 at 9:26 AM, Steve King < > [email protected] <mailto:[email protected]> <mailto: > [email protected] <mailto:[email protected]>>> wrote: > > > Multi-homing was not a requirement. It was an alternate > justification. I can?t honestly meet the 50% utilization requirement for a > /24, but under the pre-September rules I qualified for a /24 under 4.3.2.2 > because I contract with multiple carriers and want to participate in BGP > for failover. > > > > > > > > > > > > Now that the language in 4.3.2.2 is gone, my reading is I have to > either: > > > > > > > > > > > > a) Lie about my utilization. Not willing to do that. > > > > > > b) Beg for a BGP-transferrable block from a carrier, and even > then, deal with the fact that other ISPs are far more likely to aggregate > and filter specific routes to large carrier-assigned blocks. I end up with > a less reliable failover solution. > > > > > > > > > > > > The policy revision is a significant step backward for me. Maybe I?m > enough of an edge case to not matter. But ARIN-2014-13 stated 4.3.2.2 was > redundant given the lowered minimum allocation in 4.3.2.1. It was not > redundant. It covered a case that I think matters. > > > > > > > > > > > > The worst part is, I?m probably going to end up with two non-BGP > transferrable /24s from two carriers (we all know they hand them out like > candy with big circuits), so I?ll end up burning more IPV4 space than I > otherwise would. > > > > > > > > > > > > > > > > > > > > > > > > Steve King > > > > > > ICON Aircraft > > > > > > > > > > > > From: John Von Stein [mailto:[email protected] <mailto: > [email protected]> <mailto:[email protected] <mailto: > [email protected]>>] > > > Sent: Wednesday, November 19, 2014 9:18 PM > > > To: Richard J. Letts; Steve King; [email protected] <mailto: > [email protected]> <mailto:[email protected] <mailto:[email protected] > >> > > > Subject: RE: Multi-homing justification removed? > > > > > > > > > > > > Speaking from recent / current experience, the multi-homing > requirement is a bit of a challenge for tweener-sized organizations like > QxC. We are too big for underlying fiber carriers to comfortably continue > to supply our need for IP addresses but not in the position to carry the > financial, technical or operational challenges of multi-homing. This was a > very significant cost commitment for QxC and I can imagine this is not > achievable for other like-sized ISPs. Granted, we are better off for it > now but had I known how much of a financial and technical hurdle this > really was then I probably would not have done it. I just needed more IP > addresses to continue to grow my biz and would have much rather spent the > money and manpower on marketing/sales/customer acquisition. Multi-homing > is a nice-to-have luxury that none of my customers are willing to pay for > so it is simply a cost of entry to get the IP addresses we need to continue > to grow our customer base. > > > > > > > > > > > > As such, I support dropping multi-homing as a prerequisite for an IP > allocation. > > > > > > > > > > > > Thank you, > > > > > > John W. Von Stein > > > > > > CEO > > > > > > > > > > > > <image001.jpg> > > > > > > > > > > > > 102 NE 2nd Street > > > > > > Suite 136 > > > > > > Boca Raton, FL 33432 > > > > > > Office: 561-288-6989 <tel:561-288-6989> <tel:561-288-6989 <tel: > 561-288-6989>> > > > www.QxCcommunications.com <http://www.qxccommunications.com/> < > http://www.qxccommunications.com/ <http://www.qxccommunications.com/>> > > > > > > > > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. > > > > > > > > > > > > From: [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > [mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>] > On Behalf Of Richard J. Letts > > > Sent: Wednesday, November 19, 2014 1:24 PM > > > To: Steve King; [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > > > Subject: Re: [arin-ppml] Multi-homing justification removed? > > > > > > > > > > > > I believe the intent was there. > > > > > > > > > > > > orgs that have a justifiable/provable need for a /24 were been > restricted by their current/lone provider being unwilling to give them > enough address space. Not everyone has the ability to change providers, and > if you can?t change providers then you certainly would not be able to > multihome.. > > > > > > > > > > > > Richard Letts > > > > > > > > > > > > From: [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > [mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>] > On Behalf Of Steve King > > > Sent: Wednesday, November 19, 2014 9:47 AM > > > To: [email protected] <mailto:[email protected]> <mailto: > [email protected] <mailto:[email protected]>> > > > Subject: [arin-ppml] Multi-homing justification removed? > > > > > > > > > > > > The changes implemented in ARIN-2014-13, specifically the removal of > 4.3.2.2, appear to have removed the multi-homing justification for a /24 > for end users. Previously, the need to multi-home, and proof of contracts > with multiple upstream providers, was sufficient to justify a /24 to > participate in BGP. > > > > > > > > > > > > For reassignments from ISPs, the language remains in 4.2.3.6. Users > can justify a /24 via a requirement to multi-home rather than utilization > rate. However this revision appears to leave utilization rate as the only > criterion for direct end-user assignments. > > > > > > > > > > > > Was this the intent or possibly an overlooked side effect of the > change? > > > > > > > > > > > > > > > > > > > > > > > > Steve King > > > > > > ICON Aircraft > > > > > > > > > > > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to > > > the ARIN Public Policy Mailing List ([email protected] <mailto: > [email protected]> <mailto:[email protected] <mailto:[email protected] > >>). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml < > http://lists.arin.net/mailman/listinfo/arin-ppml> < > http://lists.arin.net/mailman/listinfo/arin-ppml < > http://lists.arin.net/mailman/listinfo/arin-ppml>> > > > Please contact [email protected] <mailto:[email protected]> <mailto: > [email protected] <mailto:[email protected]>> if you experience any issues. > > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to > > > the ARIN Public Policy Mailing List ([email protected] <mailto: > [email protected]>). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml < > http://lists.arin.net/mailman/listinfo/arin-ppml> > > > Please contact [email protected] <mailto:[email protected]> if you experience > any issues. > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20141201/28186cf1/attachment.html > < > http://lists.arin.net/pipermail/arin-ppml/attachments/20141201/28186cf1/attachment.html > >> > > > > ------------------------------ > > > > _______________________________________________ > > ARIN-PPML mailing list > > [email protected] <mailto:[email protected]> > > http://lists.arin.net/mailman/listinfo/arin-ppml < > http://lists.arin.net/mailman/listinfo/arin-ppml> > > > > End of ARIN-PPML Digest, Vol 114, Issue 1 > > ***************************************** > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List ([email protected]). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact [email protected] if you experience any issues. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20141202/39d2b096/attachment.html > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > [email protected] > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 114, Issue 4 > ***************************************** >
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
