<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:"times new roman",serif;font-size:large"><font color="#999999" style="background-color:rgb(255,255,255)">Re:
IMHO, the problem is no longer one of IPv4 scarcity. Yes, IPv4 is scarce, but that?s _NOT_ the real problem at this point. ( Owen)</font></div><div class="gmail_default" style="font-family:times new roman,serif;font-size:large;color:#000000">In support of this opinion. Wholeheartedly! The lack of IPv6 adoption makes IPv4 look like a narcissistic internet business disorder or NBD for short. (tgif and stay safe !)</div><div class="gmail_default" style="font-family:times new roman,serif;font-size:large;color:#000000"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><font size="4"><span style="font-family:comic sans ms,sans-serif">Rudi Daniel</span></font><div><font size="4"><span style="font-family:comic sans ms,sans-serif"><i><a href="http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774" target="_blank">danielcharles consulting</a></i></span></font></div><div><font size="4"><span style="font-family:comic sans ms,sans-serif">1 784 430 9235</span></font></div><div><font size="4"><span style="font-family:comic sans ms,sans-serif">........ict4d........</span></font></div><div><font color="#006600"><span style="font-size:large"><b><br></b></span></font><div><span style="font-size:large"><br></span></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 17, 2020 at 2:36 PM <<a href="mailto:arin-ppml-request@arin.net">arin-ppml-request@arin.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send ARIN-PPML mailing list submissions to<br>
<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/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" target="_blank">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" target="_blank">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: Draft Policy ARIN-2020-2: Grandfathering of Organizations<br>
Removed from Waitlist by Implementation of ARIN-2019-16 (Owen DeLong)<br>
2. Re: Draft Policy ARIN-2020-5: Clarify and Update Requirements<br>
for Allocations to Downstream Customers (Chris Woodfield)<br>
3. Re: Draft Policy ARIN-2020-2: Grandfathering of Organizations<br>
Removed from Waitlist by Implementation of ARIN-2019-16 (Brian Jones)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 17 Jul 2020 09:51:31 -0700<br>
From: Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>><br>
To: Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.com</a>><br>
Cc: <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>
Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of<br>
Organizations Removed from Waitlist by Implementation of ARIN-2019-16<br>
Message-ID: <<a href="mailto:2AB74F92-069C-4D0C-B014-CC2B5DB599AF@delong.com" target="_blank">2AB74F92-069C-4D0C-B014-CC2B5DB599AF@delong.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Let us be clear about this?<br>
<br>
IMHO, the problem is no longer one of IPv4 scarcity. Yes, IPv4 is scarce, but that?s _NOT_ the real problem at this point.<br>
<br>
The real problem today is lack of IPv6 deployment. If IPv6 were ubiquitously deployed as it should have been long ago, the<br>
scarcity of IPv4 would be utterly irrelevant.<br>
<br>
Owen<br>
<br>
<br>
> On Jul 17, 2020, at 09:01 , Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.com</a>> wrote:<br>
> <br>
> What is the justification to give organization who already have some reasonable space to work with, more space in current times ?<br>
> <br>
> Everybody is suffering from the same problem of IPv4 scarcity and that affects all equally. If we have already a policy that limits on /20 it is for a reason, a fair reason by the way. So why are we going to bend it in this case in the other direction ?<br>
> I see this type of proposal privileging just a few rather than been equalized to all others.<br>
> <br>
> Therefore I keep opposed to it.<br>
> <br>
> Fernando<br>
> <br>
> On 17/07/2020 12:24, Steven Ryerse via ARIN-PPML wrote:<br>
>> +1<br>
>> <br>
>> <br>
>> Steven Ryerse<br>
>> President<br>
>> <br>
>> <a href="mailto:sryerse@eclipse-networks.com" target="_blank">sryerse@eclipse-networks.com</a> | C: 770.656.1460<br>
>> 100 Ashford Center North | Suite 110 | Atlanta, Georgia 30338<br>
>> <br>
>> <br>
>> <br>
>> <br>
>> -----Original Message-----<br>
>> From: ARIN-PPML <<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a>> On Behalf Of Mike Burns<br>
>> Sent: Friday, July 17, 2020 10:59 AM<br>
>> To: <a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a>; <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of Organizations Removed from Waitlist by Implementation of ARIN-2019-16<br>
>> <br>
>> I support the policy as written and I do not believe we should prioritize small holders over large holders.<br>
>> Large holders pay higher fees but I don't see the rationale behind favoring small holders on the wait list.<br>
>> All holders should be on equal footing, we never had a new-entrant reserve at ARIN and I think if that is something we want to do, it should be discussed openly and not inserted through the back door of waitlist policy.<br>
>> <br>
>> Regards,<br>
>> Mike<br>
>> <br>
>> <br>
>> <br>
>> -----Original Message-----<br>
>> From: ARIN-PPML <<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a>> On Behalf Of <a href="mailto:hostmaster@uneedus.com" target="_blank">hostmaster@uneedus.com</a><br>
>> Sent: Thursday, July 16, 2020 7:59 AM<br>
>> To: <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of Organizations Removed from Waitlist by Implementation of ARIN-2019-16<br>
>> <br>
>> I am also against this proposal.<br>
>> <br>
>> If we allow holders of larger blocks back onto the list, we take away blocks that should go to smaller holders.<br>
>> <br>
>> The waiting list is NOT a lottery to be "won", and I think the policy should not change.<br>
>> <br>
>> Albert Erdmann<br>
>> Network Administrator<br>
>> Paradise On Line Inc.<br>
>> <br>
>> <br>
>> On Wed, 15 Jul 2020, Andrew Dul wrote:<br>
>> <br>
>>> I do not support the reintroduction of organizations onto the<br>
>>> wait-list who were removed due to having existing address holdings<br>
>>> larger than a /20. Being on the wait-list was never a guarantee that<br>
>>> you would receive space. The AC had to balance the various elements<br>
>>> of<br>
>> block size and organizations who would be eligible to receive space under the updated policy and we were aware that the rules as implemented would prevent some organizations on the wait-list from receiving blocks going forward.<br>
>>> Speaking only for myself, not the AC<br>
>>> <br>
>>> Andrew<br>
>>> <br>
>>> On 6/19/2020 11:25 AM, Alyssa Moore wrote:<br>
>>> Hi folks,<br>
>>> <br>
>>> There was some great discussion of this policy proposal at ARIN45.<br>
>> We hear a wide range of views including:<br>
>>> 1. Don't grandfather organizations. The new waitlist policy is<br>
>> sound.<br>
>>> 2. Organizations that were on the waitlist before 2019-16<br>
>>> should be<br>
>> eligible for their original request size (even if it exceeds the new limit<br>
>>> of a /22).<br>
>>> 3. Organizations that were on the waitlist before 2019-16<br>
>>> should<br>
>> remain eligible if their holdings exceed a /20 OR a /18. The draft policy<br>
>>> under discussion specifies a /18 total holdings for<br>
>> grandfathered orgs, while the current waitlist policy (2019-16) specifies a /20.<br>
>>> 4. Organizations that were on the waitlist before 2019-16<br>
>>> should be<br>
>> eligible regardless of their total holdings because that was not a<br>
>>> restriction of the policy under which they originally<br>
>>> qualified<br>
>> for the waitlist.<br>
>>> There was general support to continue finessing this draft. If<br>
>>> you<br>
>> have views on the above noted parameters, please make them known here.<br>
>>> For reference:<br>
>>> <br>
>>> Old waitlist policy<br>
>>> 1. Requester specifies smallest block they'd be willing to accept,<br>
>>> equal<br>
>> to or larger than the applicable minimum size specified elsewhere in ARIN<br>
>>> policy.<br>
>>> 2. Did not place a limit on the total existing IP address holdings of<br>
>>> a<br>
>> party eligible for the waitlist.<br>
>>> 3. Made resources issued from the waitlist ineligible for transfer<br>
>>> until after a period of 12 months. New Waitlist Policy 1. Limits the<br>
>>> size of block ARIN can issue on the waitlist to a /22.<br>
>>> 2. Places a limit on the total existing IP address holdings of a<br>
>>> party<br>
>> eligible for the waitlist at a /20 or less.<br>
>>> 3. Makes resources issued from the waitlist ineligible for transfer<br>
>>> until after a period of 60 months.<br>
>>> <br>
>>> Best,<br>
>>> Alyssa<br>
>>> <br>
>>> On Thu, Mar 26, 2020 at 3:35 PM David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:<br>
>>> I support this policy and believe the policy development process<br>
>>> is<br>
>> the proper place to handle this issue. However, this policy seems to<br>
>>> be implementable as a one-time policy directive to ARIN Staff.<br>
>>> Once<br>
>> implemented, by putting the effected organizations back on the waiting<br>
>>> list, it seems unnecessary to memorialized the text in the NRPM,<br>
>>> it<br>
>> would immediately become extraneous and potentially confusing to<br>
>>> future readers of the NRPM.<br>
>>> Therefore, I would like to recommend the Policy Statement not be added<br>
>>> to the NRPM upon its implementation. I believe this to be consistent<br>
>>> with<br>
>> the intent of the policy. Otherwise, does ARIN Staff have procedural advice on how best to handle what seems like a one-time directive?<br>
>>> Thanks<br>
>>> <br>
>>> On Tue, Mar 24, 2020 at 12:21 PM ARIN <<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>> wrote:<br>
>>> <br>
>>> Draft Policy ARIN-2020-2: Grandfathering of Organizations<br>
>>> Removed<br>
>> from<br>
>>> Waitlist by Implementation of ARIN-2019-16<br>
>>> <br>
>>> Problem Statement:<br>
>>> <br>
>>> The implementation of the ARIN-2019-16 Advisory Council<br>
>> Recommendation<br>
>>> Regarding NRPM 4.1.8: Unmet Requests caused some organizations to be<br>
>>> removed from the waiting list that were approved under the old<br>
>> policy?s<br>
>>> eligibility criteria. These organizations should have been<br>
>> grandfathered<br>
>>> when the waitlist was reopened to allow them to receive an<br>
>> allocation of<br>
>>> IPv4 up to the new policy?s maximum size constraint of a /22.<br>
>>> <br>
>>> Policy Statement: Update NRPM Section 4.1.8 as follows:<br>
>>> <br>
>>> Add section 4.1.8.3 (temporary language in the NRPM to remain<br>
>>> until<br>
>> the<br>
>>> policy objective is achieved)<br>
>>> <br>
>>> Restoring organizations to the waitlist<br>
>>> <br>
>>> ARIN will restore organizations that were removed from the<br>
>>> waitlist<br>
>> at<br>
>>> the adoption of ARIN-2019-16 to their previous position if their<br>
>> total<br>
>>> holdings of IPv4 address space amounts to a /18 or less. The maximum<br>
>>> size aggregate that a reinstated organization may qualify for is<br>
>>> a<br>
>> /22.<br>
>>> All restored organizations extend their 2 year approval by<br>
>>> [number<br>
>> of<br>
>>> months between July 2019 and implementation of new policy]. Any<br>
>> requests<br>
>>> met through a transfer will be considered fulfilled and removed<br>
>>> from<br>
>> the<br>
>>> waiting list.<br>
>>> <br>
>>> Comments:<br>
>>> <br>
>>> Timetable for implementation: Immediate<br>
>>> <br>
>>> Anything Else: While attending ARIN 44 and discussing this with<br>
>> other<br>
>>> community members the vast majority indicated that they agreed<br>
>>> that<br>
>> some<br>
>>> organizations were treated unfairly. This proposal is a remedy.<br>
>>> _______________________________________________<br>
>>> ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>
>>> Unsubscribe or manage your mailing list subscription at:<br>
>>> <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&c=E,1,itejYWK1neA4HwQI2654uD6T84LDr-jtyvegBUSRLaqI3i7cGDsXGSLO9kZFAeEqibHLpNp9IQUPINbrQtts-4t2a9DQNRIijWuYbVTpZdvZJI2YmIU7zQMg&typo=1" rel="noreferrer" target="_blank">https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&c=E,1,itejYWK1neA4HwQI2654uD6T84LDr-jtyvegBUSRLaqI3i7cGDsXGSLO9kZFAeEqibHLpNp9IQUPINbrQtts-4t2a9DQNRIijWuYbVTpZdvZJI2YmIU7zQMg&typo=1</a><br>
>>> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
>>> <br>
>>> <br>
>>> <br>
>>> --<br>
>>> ===============================================<br>
>>> David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a> Networking &<br>
>>> Telecommunication Services Office of Information Technology University<br>
>>> of Minnesota<br>
>>> 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN<br>
>>> 55414-3029 Cell: 612-812-9952<br>
>>> ===============================================<br>
>>> _______________________________________________<br>
>>> ARIN-PPML<br>
>>> You are receiving this message because you are subscribed to the ARIN<br>
>>> Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
>>> Unsubscribe or manage your mailing list subscription at:<br>
>>> <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fm" rel="noreferrer" target="_blank">https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fm</a><br>
>>> ailman%2flistinfo%2farin-ppml&c=E,1,pr8_yOATR6fbNAoiwPjuIuQtJCW1Nm7qlk<br>
>>> KG7uppvzhqUtK33qz6GCTJCwHGGeKePdcEaJZZdUUw-RTujqMB1FJ2DG6HTd2r6GM5s4Hy<br>
>>> nLV4b0vI3AnQPQ,,&typo=1 Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience<br>
>>> any issues.<br>
>>> <br>
>>> <br>
>>> _______________________________________________<br>
>>> ARIN-PPML<br>
>>> You are receiving this message because you are subscribed to the ARIN<br>
>>> Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
>>> Unsubscribe or manage your mailing list subscription at:<br>
>>> <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fm" rel="noreferrer" target="_blank">https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fm</a><br>
>>> ailman%2flistinfo%2farin-ppml&c=E,1,RsBXYYW2wGypb0Y4GbeHTbKFC2827Z3jsp<br>
>>> at1aezQl0yTqcY6d2pTdFdOAraqUCnPZ-okcO1-ObFc2thTsKxGhJ1eTCN_Cv8UpPoW80d<br>
>>> 6gOeCMy96nbc8z4g0yY0&typo=1 Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you<br>
>>> experience any issues.<br>
>>> <br>
>>> <br>
>>> <br>
>> _______________________________________________<br>
>> ARIN-PPML<br>
>> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&c=E,1,PZT3k6xZlfRBghEBxxufd4mu2Ve_KsVjNFFbz6LOCh9lpSIRtyNyDCvryXvevPimoqYvm4gDqykjaXQTjrj8V6QM-AY3-lYKC-1oXXBA-awSsCEN&typo=1" rel="noreferrer" target="_blank">https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&c=E,1,PZT3k6xZlfRBghEBxxufd4mu2Ve_KsVjNFFbz6LOCh9lpSIRtyNyDCvryXvevPimoqYvm4gDqykjaXQTjrj8V6QM-AY3-lYKC-1oXXBA-awSsCEN&typo=1</a><br>
>> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
>> _______________________________________________<br>
>> ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
> _______________________________________________<br>
> ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 17 Jul 2020 10:25:35 -0700<br>
From: Chris Woodfield <<a href="mailto:chris@semihuman.com" target="_blank">chris@semihuman.com</a>><br>
To: <a href="mailto:john@egh.com" target="_blank">john@egh.com</a><br>
Cc: arin-ppml <<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] Draft Policy ARIN-2020-5: Clarify and Update<br>
Requirements for Allocations to Downstream Customers<br>
Message-ID: <<a href="mailto:72FC5CAE-E26A-4E28-BA2F-9EB882A39F0D@semihuman.com" target="_blank">72FC5CAE-E26A-4E28-BA2F-9EB882A39F0D@semihuman.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
> On Jul 16, 2020, at 11:06 AM, John Santos <<a href="mailto:john@egh.com" target="_blank">john@egh.com</a>> wrote:<br>
> <br>
> On 7/16/2020 11:39 AM, Kat Hunter wrote:<br>
> [...]<br>
>> 4.2.3.6 Original Text:<br>
>> Under normal circumstances an ISP is required to determine the prefix size of their reassignment to a downstream customer according to the guidelines set forth in RFC 2050. Specifically, a downstream customer justifies their reassignment by demonstrating they have an immediate requirement for 25% of the IP addresses being assigned, and that they have a plan to utilize 50% of their assignment within one year of its receipt. This policy allows a downstream customer?s multihoming requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements. Downstream customers must provide contact information for all of their upstream providers to the ISP from whom they are requesting a /24. The ISP will then verify the customer?s multihoming requirement and may assign the customer a /24, based on this policy. Customers may receive a /24 from only one of their upstream providers under this policy without providing additional justificat<br>
ion. ISPs may demonstrate they have made an assignment to a downstream customer under this policy by supplying ARIN with the information they collected from the customer, as described above, or by identifying the AS number of the customer. This information may be requested by ARIN staff when reviewing an ISP?s utilization during their request for additional IP addresses space.<br>
>> <br>
> New version of proposed 4.2.3.6 replacement:<br>
> <br>
>> 4.3.2.6 New Text, replacing old:<br>
>> If a downstream customer has a requirement to multihome, that requirement alone will serve as justification for a /24 allocation. Downstream customers must provide contact information for all of their upstream providers to the ISP from whom they are requesting a /24, and utilize BGP as the routing protocol between the customer and the ISP. Customers may receive a /24 from only one of their upstream providers under this policy without providing additional justification. ISPs may demonstrate they have made an assignment to a downstream customer under this policy by supplying ARIN with the information they collected from the customer, as described above, or by identifying the AS number of the customer.<br>
>> <br>
>> -Kat Hunter<br>
>> [...]<br>
> Older version of proposed <a href="http://4.2.3.6" rel="noreferrer" target="_blank">4.2.3.6</a>:<br>
>> <br>
>> 4.2.3.6. Reassignments to Multihomed Downstream Customers<br>
>> <br>
>> If a downstream customer has a requirement to multihome, that <br>
>> requirement alone will serve as justification for a /24 allocation. <br>
>> Downstream customers must provide contact information for all of their <br>
>> upstream providers to the ISP from whom they are requesting a /24, and <br>
>> utilize BGP as the routing protocol between the customer and the ISP. <br>
>> Customers may receive a /24 from only one of their upstream providers <br>
>> under this policy without providing additional justification. ISPs may <br>
>> demonstrate they have made an assignment to a downstream customer under <br>
>> this policy by supplying ARIN with the information they collected from <br>
>> the customer, as described above, or by identifying the AS number of the <br>
>> customer.<br>
>> <br>
>> Timetable for implementation: Immediate<br>
> I haven't digested this proposal sufficiently to have an opinion one way or the other, but I do have a general and a specific question. Doesn't ARIN attempt to avoid mandating particular network technologies in policy, so as not to impede technological advances?<br>
> <br>
> I am particularly referring to BGP in both versions of the proposed new policy. Would it be better to develop wording that would suggest BGP until something better comes along, by not specifically refer to it in the policy text? Or is BGP considered to be as good as it's ever going to get, at least for IPv4 routing?<br>
> <br>
> <br>
> <br>
Speaking as one fo the proposal's authors, I appreciate and agree with that bit of feedback. The intent was to express the requirement that the customer route the prefix over multiple upstream ISPs; while in practical terms, BGP is the only reasonable way to do this, the policy text should not preclude other approaches.<br>
<br>
Thanks,<br>
<br>
-C<br>
<br>
> -- <br>
> John Santos<br>
> Evans Griffiths & Hart, Inc.<br>
> 781-861-0670 ext 539<br>
> _______________________________________________<br>
> ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.arin.net/pipermail/arin-ppml/attachments/20200717/b0eb2730/attachment-0001.htm" rel="noreferrer" target="_blank">https://lists.arin.net/pipermail/arin-ppml/attachments/20200717/b0eb2730/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 17 Jul 2020 14:35:37 -0400<br>
From: Brian Jones <<a href="mailto:bjones@vt.edu" target="_blank">bjones@vt.edu</a>><br>
To: Tom Pruitt <<a href="mailto:tpruitt@stratusnet.com" target="_blank">tpruitt@stratusnet.com</a>><br>
Cc: A N <<a href="mailto:anita.nikolich@gmail.com" target="_blank">anita.nikolich@gmail.com</a>>, ARIN-PPML List<br>
<<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>><br>
Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of<br>
Organizations Removed from Waitlist by Implementation of ARIN-2019-16<br>
Message-ID:<br>
<<a href="mailto:CANyqO%2BFHu4XWe8QRdHQOn83QmcHav39jFR1Km4FKbdrVueJb5Q@mail.gmail.com" target="_blank">CANyqO+FHu4XWe8QRdHQOn83QmcHav39jFR1Km4FKbdrVueJb5Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I +1 Tom's input below. I think the organizations that were on the waiting<br>
list before should receive the same benefits and restrictions they were<br>
given in the original vetting process when they were placed onto the<br>
waiting list.<br>
<br>
I also +1 Owen's comment about yes IPv4 is scarce but that's not the<br>
problem. IMHO - IPv6 should be the first consideration of anyone looking to<br>
implement networks now. As long as "we" keep placing high value on IPv4<br>
addresses "we" are prolonging the adoption of IPv6, the technology of today<br>
and the future.<br>
?<br>
Brian<br>
<br>
On Fri, Jul 17, 2020 at 9:26 AM Tom Pruitt <<a href="mailto:tpruitt@stratusnet.com" target="_blank">tpruitt@stratusnet.com</a>> wrote:<br>
<br>
> I support the draft policy as written, which addresses grandfathering<br>
> organizations<br>
><br>
><br>
><br>
> Views 2, 3, and 4 seem to be addressing the list as a whole, which I would<br>
> also support, but this draft policy was brought up to address the situation<br>
> that happened when 2019-16 was implemented and dropped some organizations<br>
> from the wait list.<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> Tom Pruitt<br>
><br>
> Network Engineer<br>
><br>
> Stratus Networks<br>
><br>
> [image: stratus_networks_logo_FINAL]<br>
><br>
> This e-mail, and any files transmitted with it are the property of Stratus<br>
> Networks, Inc. and/or its affiliates, are confidential, and are intended<br>
> solely for the use of the individual or entity to whom this e-mail is<br>
> addressed. If you are not one of the named recipient(s) or otherwise have<br>
> reason to believe that you have received this message in error, please<br>
> notify the sender at 309-408-8704 and delete this message immediately from<br>
> your computer. Any other use, retention, dissemination, forwarding,<br>
> printing, or copying of this e-mail is strictly prohibited<br>
><br>
><br>
><br>
> *From:* ARIN-PPML <<a href="mailto:arin-ppml-bounces@arin.net" target="_blank">arin-ppml-bounces@arin.net</a>> *On Behalf Of *A N<br>
> *Sent:* Friday, July 17, 2020 7:56 AM<br>
> *To:* ARIN-PPML List <<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>><br>
> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of<br>
> Organizations Removed from Waitlist by Implementation of ARIN-2019-16<br>
><br>
><br>
><br>
> Hi all -<br>
><br>
> Alyssa and I are shepherding this on behalf of the AC. Given the varying,<br>
> thoughtful opinions, I'd like to prod to see if anyone else has thoughts<br>
> one way or the other on this draft.<br>
><br>
><br>
><br>
> Anita<br>
><br>
><br>
><br>
> On Fri, Jun 19, 2020 at 6:26 PM Alyssa Moore <<a href="mailto:alyssa@alyssamoore.ca" target="_blank">alyssa@alyssamoore.ca</a>><br>
> wrote:<br>
><br>
> Hi folks,<br>
><br>
> There was some great discussion of this policy proposal at ARIN45. We hear<br>
> a wide range of views including:<br>
><br>
> 1. Don't grandfather organizations. The new waitlist policy is sound.<br>
> 2. Organizations that were on the waitlist before 2019-16 should be<br>
> eligible for their original request size (even if it exceeds the new limit<br>
> of a /22).<br>
> 3. Organizations that were on the waitlist before 2019-16 should<br>
> remain eligible if their holdings exceed a /20 OR a /18. The draft policy<br>
> under discussion specifies a /18 total holdings for grandfathered orgs,<br>
> while the current waitlist policy (2019-16) specifies a /20.<br>
> 4. Organizations that were on the waitlist before 2019-16 should be<br>
> eligible regardless of their total holdings because that was not a<br>
> restriction of the policy under which they originally qualified for the<br>
> waitlist.<br>
><br>
> There was general support to continue finessing this draft. If you have<br>
> views on the above noted parameters, please make them known here.<br>
><br>
><br>
><br>
> For reference:<br>
><br>
> *Old waitlist policy*<br>
><br>
> 1. Requester specifies smallest block they'd be willing to accept,<br>
> equal to or larger than the applicable minimum size specified elsewhere in<br>
> ARIN policy.<br>
> 2. Did not place a limit on the total existing IP address holdings of<br>
> a party eligible for the waitlist.<br>
> 3. Made resources issued from the waitlist ineligible for transfer<br>
> until after a period of 12 months.<br>
><br>
> *New Waitlist Policy*<br>
><br>
> 1. Limits the size of block ARIN can issue on the waitlist to a /22.<br>
> 2. Places a limit on the total existing IP address holdings of a party<br>
> eligible for the waitlist at a /20 or less.<br>
> 3. Makes resources issued from the waitlist ineligible for transfer<br>
> until after a period of 60 months.<br>
><br>
><br>
> Best,<br>
> Alyssa<br>
><br>
><br>
><br>
> On Thu, Mar 26, 2020 at 3:35 PM David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:<br>
><br>
> I support this policy and believe the policy development process is the<br>
> proper place to handle this issue. However, this policy seems to be<br>
> implementable as a one-time policy directive to ARIN Staff. Once<br>
> implemented, by putting the effected organizations back on the waiting<br>
> list, it seems unnecessary to memorialized the text in the NRPM, it would<br>
> immediately become extraneous and potentially confusing to future readers<br>
> of the NRPM.<br>
><br>
><br>
><br>
> Therefore, I would like to recommend the Policy Statement not be added to<br>
> the NRPM upon its implementation. I believe this to be consistent with the<br>
> intent of the policy. Otherwise, does ARIN Staff have procedural advice on<br>
> how best to handle what seems like a one-time directive?<br>
><br>
><br>
><br>
> Thanks<br>
><br>
><br>
><br>
> On Tue, Mar 24, 2020 at 12:21 PM ARIN <<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>> wrote:<br>
><br>
><br>
> Draft Policy ARIN-2020-2: Grandfathering of Organizations Removed from<br>
> Waitlist by Implementation of ARIN-2019-16<br>
><br>
> Problem Statement:<br>
><br>
> The implementation of the ARIN-2019-16 Advisory Council Recommendation<br>
> Regarding NRPM 4.1.8: Unmet Requests caused some organizations to be<br>
> removed from the waiting list that were approved under the old policy?s<br>
> eligibility criteria. These organizations should have been grandfathered<br>
> when the waitlist was reopened to allow them to receive an allocation of<br>
> IPv4 up to the new policy?s maximum size constraint of a /22.<br>
><br>
> Policy Statement: Update NRPM Section 4.1.8 as follows:<br>
><br>
> Add section 4.1.8.3 (temporary language in the NRPM to remain until the<br>
> policy objective is achieved)<br>
><br>
> Restoring organizations to the waitlist<br>
><br>
> ARIN will restore organizations that were removed from the waitlist at<br>
> the adoption of ARIN-2019-16 to their previous position if their total<br>
> holdings of IPv4 address space amounts to a /18 or less. The maximum<br>
> size aggregate that a reinstated organization may qualify for is a /22.<br>
><br>
> All restored organizations extend their 2 year approval by [number of<br>
> months between July 2019 and implementation of new policy]. Any requests<br>
> met through a transfer will be considered fulfilled and removed from the<br>
> waiting list.<br>
><br>
> Comments:<br>
><br>
> Timetable for implementation: Immediate<br>
><br>
> Anything Else: While attending ARIN 44 and discussing this with other<br>
> community members the vast majority indicated that they agreed that some<br>
> organizations were treated unfairly. This proposal is a remedy.<br>
> _______________________________________________<br>
> ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
><br>
><br>
><br>
><br>
> --<br>
><br>
> ===============================================<br>
> David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>
> Networking & Telecommunication Services<br>
> Office of Information Technology<br>
> University of Minnesota<br>
> 2218 University Ave SE Phone: 612-626-0815<br>
> Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>
> ===============================================<br>
><br>
> _______________________________________________<br>
> ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
><br>
> _______________________________________________<br>
> ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
><br>
> _______________________________________________<br>
> ARIN-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" target="_blank">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.arin.net/pipermail/arin-ppml/attachments/20200717/29438be3/attachment.htm" rel="noreferrer" target="_blank">https://lists.arin.net/pipermail/arin-ppml/attachments/20200717/29438be3/attachment.htm</a>><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: image001.png<br>
Type: image/png<br>
Size: 15673 bytes<br>
Desc: not available<br>
URL: <<a href="https://lists.arin.net/pipermail/arin-ppml/attachments/20200717/29438be3/attachment.png" rel="noreferrer" target="_blank">https://lists.arin.net/pipermail/arin-ppml/attachments/20200717/29438be3/attachment.png</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
ARIN-PPML mailing list<br>
<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a><br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
<br>
<br>
------------------------------<br>
<br>
End of ARIN-PPML Digest, Vol 181, Issue 20<br>
******************************************<br>
</blockquote></div></div><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br>
<table style="border-top:1px solid #d3d4de">
<tr>
<td style="width:55px;padding-top:13px"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;"></a></td>
<td style="width:470px;padding-top:12px;color:#41424e;font-size:13px;font-family:Arial,Helvetica,sans-serif;line-height:18px">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link" target="_blank" style="color:#4453ea">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div>