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) 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 !)
Rudi Daniel *danielcharles consulting <http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774>* 1 784 430 9235 ........ict4d........ On Fri, Jul 17, 2020 at 2:36 PM <arin-ppml-requ...@arin.net> wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml@arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-requ...@arin.net > > You can reach the person managing the list at > arin-ppml-ow...@arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Draft Policy ARIN-2020-2: Grandfathering of Organizations > Removed from Waitlist by Implementation of ARIN-2019-16 (Owen DeLong) > 2. Re: Draft Policy ARIN-2020-5: Clarify and Update Requirements > for Allocations to Downstream Customers (Chris Woodfield) > 3. Re: Draft Policy ARIN-2020-2: Grandfathering of Organizations > Removed from Waitlist by Implementation of ARIN-2019-16 (Brian Jones) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 17 Jul 2020 09:51:31 -0700 > From: Owen DeLong <o...@delong.com> > To: Fernando Frediani <fhfredi...@gmail.com> > Cc: arin-ppml@arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of > Organizations Removed from Waitlist by Implementation of > ARIN-2019-16 > Message-ID: <2ab74f92-069c-4d0c-b014-cc2b5db59...@delong.com> > Content-Type: text/plain; charset=utf-8 > > Let us be clear about this? > > IMHO, the problem is no longer one of IPv4 scarcity. Yes, IPv4 is scarce, > but that?s _NOT_ the real problem at this point. > > The real problem today is lack of IPv6 deployment. If IPv6 were > ubiquitously deployed as it should have been long ago, the > scarcity of IPv4 would be utterly irrelevant. > > Owen > > > > On Jul 17, 2020, at 09:01 , Fernando Frediani <fhfredi...@gmail.com> > wrote: > > > > What is the justification to give organization who already have some > reasonable space to work with, more space in current times ? > > > > 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 ? > > I see this type of proposal privileging just a few rather than been > equalized to all others. > > > > Therefore I keep opposed to it. > > > > Fernando > > > > On 17/07/2020 12:24, Steven Ryerse via ARIN-PPML wrote: > >> +1 > >> > >> > >> Steven Ryerse > >> President > >> > >> srye...@eclipse-networks.com | C: 770.656.1460 > >> 100 Ashford Center North | Suite 110 | Atlanta, Georgia 30338 > >> > >> > >> > >> > >> -----Original Message----- > >> From: ARIN-PPML <arin-ppml-boun...@arin.net> On Behalf Of Mike Burns > >> Sent: Friday, July 17, 2020 10:59 AM > >> To: hostmas...@uneedus.com; arin-ppml@arin.net > >> Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of > Organizations Removed from Waitlist by Implementation of ARIN-2019-16 > >> > >> I support the policy as written and I do not believe we should > prioritize small holders over large holders. > >> Large holders pay higher fees but I don't see the rationale behind > favoring small holders on the wait list. > >> 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. > >> > >> Regards, > >> Mike > >> > >> > >> > >> -----Original Message----- > >> From: ARIN-PPML <arin-ppml-boun...@arin.net> On Behalf Of > hostmas...@uneedus.com > >> Sent: Thursday, July 16, 2020 7:59 AM > >> To: arin-ppml@arin.net > >> Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of > Organizations Removed from Waitlist by Implementation of ARIN-2019-16 > >> > >> I am also against this proposal. > >> > >> If we allow holders of larger blocks back onto the list, we take away > blocks that should go to smaller holders. > >> > >> The waiting list is NOT a lottery to be "won", and I think the policy > should not change. > >> > >> Albert Erdmann > >> Network Administrator > >> Paradise On Line Inc. > >> > >> > >> On Wed, 15 Jul 2020, Andrew Dul wrote: > >> > >>> I do not support the reintroduction of organizations onto the > >>> wait-list who were removed due to having existing address holdings > >>> larger than a /20. Being on the wait-list was never a guarantee that > >>> you would receive space. The AC had to balance the various elements > >>> of > >> 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. > >>> Speaking only for myself, not the AC > >>> > >>> Andrew > >>> > >>> On 6/19/2020 11:25 AM, Alyssa Moore wrote: > >>> Hi folks, > >>> > >>> There was some great discussion of this policy proposal at > ARIN45. > >> We hear a wide range of views including: > >>> 1. Don't grandfather organizations. The new waitlist policy is > >> sound. > >>> 2. Organizations that were on the waitlist before 2019-16 > >>> should be > >> eligible for their original request size (even if it exceeds the new > limit > >>> of a /22). > >>> 3. Organizations that were on the waitlist before 2019-16 > >>> should > >> remain eligible if their holdings exceed a /20 OR a /18. The draft > policy > >>> under discussion specifies a /18 total holdings for > >> grandfathered orgs, while the current waitlist policy (2019-16) > specifies a /20. > >>> 4. Organizations that were on the waitlist before 2019-16 > >>> should be > >> eligible regardless of their total holdings because that was not a > >>> restriction of the policy under which they originally > >>> qualified > >> for the waitlist. > >>> There was general support to continue finessing this draft. If > >>> you > >> have views on the above noted parameters, please make them known here. > >>> For reference: > >>> > >>> Old waitlist policy > >>> 1. Requester specifies smallest block they'd be willing to accept, > >>> equal > >> to or larger than the applicable minimum size specified elsewhere in > ARIN > >>> policy. > >>> 2. Did not place a limit on the total existing IP address holdings of > >>> a > >> party eligible for the waitlist. > >>> 3. Made resources issued from the waitlist ineligible for transfer > >>> until after a period of 12 months. New Waitlist Policy 1. Limits the > >>> size of block ARIN can issue on the waitlist to a /22. > >>> 2. Places a limit on the total existing IP address holdings of a > >>> party > >> eligible for the waitlist at a /20 or less. > >>> 3. Makes resources issued from the waitlist ineligible for transfer > >>> until after a period of 60 months. > >>> > >>> Best, > >>> Alyssa > >>> > >>> On Thu, Mar 26, 2020 at 3:35 PM David Farmer <far...@umn.edu> wrote: > >>> I support this policy and believe the policy development process > >>> is > >> the proper place to handle this issue. However, this policy seems to > >>> be implementable as a one-time policy directive to ARIN Staff. > >>> Once > >> implemented, by putting the effected organizations back on the waiting > >>> list, it seems unnecessary to memorialized the text in the NRPM, > >>> it > >> would immediately become extraneous and potentially confusing to > >>> future readers of the NRPM. > >>> Therefore, I would like to recommend the Policy Statement not be added > >>> to the NRPM upon its implementation. I believe this to be consistent > >>> with > >> the intent of the policy. Otherwise, does ARIN Staff have procedural > advice on how best to handle what seems like a one-time directive? > >>> Thanks > >>> > >>> On Tue, Mar 24, 2020 at 12:21 PM ARIN <i...@arin.net> wrote: > >>> > >>> Draft Policy ARIN-2020-2: Grandfathering of Organizations > >>> Removed > >> from > >>> Waitlist by Implementation of ARIN-2019-16 > >>> > >>> Problem Statement: > >>> > >>> The implementation of the ARIN-2019-16 Advisory Council > >> Recommendation > >>> Regarding NRPM 4.1.8: Unmet Requests caused some organizations > to be > >>> removed from the waiting list that were approved under the old > >> policy?s > >>> eligibility criteria. These organizations should have been > >> grandfathered > >>> when the waitlist was reopened to allow them to receive an > >> allocation of > >>> IPv4 up to the new policy?s maximum size constraint of a /22. > >>> > >>> Policy Statement: Update NRPM Section 4.1.8 as follows: > >>> > >>> Add section 4.1.8.3 (temporary language in the NRPM to remain > >>> until > >> the > >>> policy objective is achieved) > >>> > >>> Restoring organizations to the waitlist > >>> > >>> ARIN will restore organizations that were removed from the > >>> waitlist > >> at > >>> the adoption of ARIN-2019-16 to their previous position if their > >> total > >>> holdings of IPv4 address space amounts to a /18 or less. The > maximum > >>> size aggregate that a reinstated organization may qualify for is > >>> a > >> /22. > >>> All restored organizations extend their 2 year approval by > >>> [number > >> of > >>> months between July 2019 and implementation of new policy]. Any > >> requests > >>> met through a transfer will be considered fulfilled and removed > >>> from > >> the > >>> waiting list. > >>> > >>> Comments: > >>> > >>> Timetable for implementation: Immediate > >>> > >>> Anything Else: While attending ARIN 44 and discussing this with > >> other > >>> community members the vast majority indicated that they agreed > >>> that > >> some > >>> organizations were treated unfairly. This proposal is a remedy. > >>> _______________________________________________ > >>> ARIN-PPML > >>> You are receiving this message because you are subscribed to > >>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > >>> Unsubscribe or manage your mailing list subscription at: > >>> > https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fmailman%2flistinfo%2farin-ppml&c=E,1,itejYWK1neA4HwQI2654uD6T84LDr-jtyvegBUSRLaqI3i7cGDsXGSLO9kZFAeEqibHLpNp9IQUPINbrQtts-4t2a9DQNRIijWuYbVTpZdvZJI2YmIU7zQMg&typo=1 > >>> Please contact i...@arin.net if you experience any issues. > >>> > >>> > >>> > >>> -- > >>> =============================================== > >>> David Farmer Email:far...@umn.edu Networking & > >>> Telecommunication Services Office of Information Technology University > >>> of Minnesota > >>> 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN > >>> 55414-3029 Cell: 612-812-9952 > >>> =============================================== > >>> _______________________________________________ > >>> ARIN-PPML > >>> You are receiving this message because you are subscribed to the ARIN > >>> Public Policy Mailing List (ARIN-PPML@arin.net). > >>> Unsubscribe or manage your mailing list subscription at: > >>> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fm > >>> ailman%2flistinfo%2farin-ppml&c=E,1,pr8_yOATR6fbNAoiwPjuIuQtJCW1Nm7qlk > >>> KG7uppvzhqUtK33qz6GCTJCwHGGeKePdcEaJZZdUUw-RTujqMB1FJ2DG6HTd2r6GM5s4Hy > >>> nLV4b0vI3AnQPQ,,&typo=1 Please contact i...@arin.net if you experience > >>> any issues. > >>> > >>> > >>> _______________________________________________ > >>> ARIN-PPML > >>> You are receiving this message because you are subscribed to the ARIN > >>> Public Policy Mailing List (ARIN-PPML@arin.net). > >>> Unsubscribe or manage your mailing list subscription at: > >>> https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.arin.net%2fm > >>> ailman%2flistinfo%2farin-ppml&c=E,1,RsBXYYW2wGypb0Y4GbeHTbKFC2827Z3jsp > >>> at1aezQl0yTqcY6d2pTdFdOAraqUCnPZ-okcO1-ObFc2thTsKxGhJ1eTCN_Cv8UpPoW80d > >>> 6gOeCMy96nbc8z4g0yY0&typo=1 Please contact i...@arin.net if you > >>> experience any issues. > >>> > >>> > >>> > >> _______________________________________________ > >> ARIN-PPML > >> You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML@arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> > 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 > >> Please contact i...@arin.net if you experience any issues. > >> _______________________________________________ > >> ARIN-PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> https://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact i...@arin.net if you experience any issues. > > _______________________________________________ > > ARIN-PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > > Unsubscribe or manage your mailing list subscription at: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact i...@arin.net if you experience any issues. > > > > ------------------------------ > > Message: 2 > Date: Fri, 17 Jul 2020 10:25:35 -0700 > From: Chris Woodfield <ch...@semihuman.com> > To: j...@egh.com > Cc: arin-ppml <arin-ppml@arin.net> > Subject: Re: [arin-ppml] Draft Policy ARIN-2020-5: Clarify and Update > Requirements for Allocations to Downstream Customers > Message-ID: <72fc5cae-e26a-4e28-ba2f-9eb882a39...@semihuman.com> > Content-Type: text/plain; charset="utf-8" > > > > On Jul 16, 2020, at 11:06 AM, John Santos <j...@egh.com> wrote: > > > > On 7/16/2020 11:39 AM, Kat Hunter wrote: > > [...] > >> 4.2.3.6 Original Text: > >> 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 > 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. > >> > > New version of proposed 4.2.3.6 replacement: > > > >> 4.3.2.6 New Text, replacing old: > >> 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. > >> > >> -Kat Hunter > >> [...] > > Older version of proposed 4.2.3.6: > >> > >> 4.2.3.6. Reassignments to Multihomed Downstream Customers > >> > >> 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. > >> > >> Timetable for implementation: Immediate > > 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? > > > > 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? > > > > > > > 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. > > Thanks, > > -C > > > -- > > John Santos > > Evans Griffiths & Hart, Inc. > > 781-861-0670 ext 539 > > _______________________________________________ > > ARIN-PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > > Unsubscribe or manage your mailing list subscription at: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact i...@arin.net if you experience any issues. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.arin.net/pipermail/arin-ppml/attachments/20200717/b0eb2730/attachment-0001.htm > > > > ------------------------------ > > Message: 3 > Date: Fri, 17 Jul 2020 14:35:37 -0400 > From: Brian Jones <bjo...@vt.edu> > To: Tom Pruitt <tpru...@stratusnet.com> > Cc: A N <anita.nikol...@gmail.com>, ARIN-PPML List > <arin-ppml@arin.net> > Subject: Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of > Organizations Removed from Waitlist by Implementation of > ARIN-2019-16 > Message-ID: > < > canyqo+fhu4xwe8qrdhqon83qmchav39jfr1km4fkbdrvuej...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I +1 Tom's input below. I think the organizations that were on the waiting > list before should receive the same benefits and restrictions they were > given in the original vetting process when they were placed onto the > waiting list. > > I also +1 Owen's comment about yes IPv4 is scarce but that's not the > problem. IMHO - IPv6 should be the first consideration of anyone looking to > implement networks now. As long as "we" keep placing high value on IPv4 > addresses "we" are prolonging the adoption of IPv6, the technology of today > and the future. > ? > Brian > > On Fri, Jul 17, 2020 at 9:26 AM Tom Pruitt <tpru...@stratusnet.com> wrote: > > > I support the draft policy as written, which addresses grandfathering > > organizations > > > > > > > > Views 2, 3, and 4 seem to be addressing the list as a whole, which I > would > > also support, but this draft policy was brought up to address the > situation > > that happened when 2019-16 was implemented and dropped some organizations > > from the wait list. > > > > > > > > Thanks, > > > > Tom Pruitt > > > > Network Engineer > > > > Stratus Networks > > > > [image: stratus_networks_logo_FINAL] > > > > This e-mail, and any files transmitted with it are the property of > Stratus > > Networks, Inc. and/or its affiliates, are confidential, and are intended > > solely for the use of the individual or entity to whom this e-mail is > > addressed. If you are not one of the named recipient(s) or otherwise have > > reason to believe that you have received this message in error, please > > notify the sender at 309-408-8704 and delete this message immediately > from > > your computer. Any other use, retention, dissemination, forwarding, > > printing, or copying of this e-mail is strictly prohibited > > > > > > > > *From:* ARIN-PPML <arin-ppml-boun...@arin.net> *On Behalf Of *A N > > *Sent:* Friday, July 17, 2020 7:56 AM > > *To:* ARIN-PPML List <arin-ppml@arin.net> > > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of > > Organizations Removed from Waitlist by Implementation of ARIN-2019-16 > > > > > > > > Hi all - > > > > Alyssa and I are shepherding this on behalf of the AC. Given the varying, > > thoughtful opinions, I'd like to prod to see if anyone else has thoughts > > one way or the other on this draft. > > > > > > > > Anita > > > > > > > > On Fri, Jun 19, 2020 at 6:26 PM Alyssa Moore <aly...@alyssamoore.ca> > > wrote: > > > > Hi folks, > > > > There was some great discussion of this policy proposal at ARIN45. We > hear > > a wide range of views including: > > > > 1. Don't grandfather organizations. The new waitlist policy is sound. > > 2. Organizations that were on the waitlist before 2019-16 should be > > eligible for their original request size (even if it exceeds the new > limit > > of a /22). > > 3. Organizations that were on the waitlist before 2019-16 should > > remain eligible if their holdings exceed a /20 OR a /18. The draft > policy > > under discussion specifies a /18 total holdings for grandfathered > orgs, > > while the current waitlist policy (2019-16) specifies a /20. > > 4. Organizations that were on the waitlist before 2019-16 should be > > eligible regardless of their total holdings because that was not a > > restriction of the policy under which they originally qualified for > the > > waitlist. > > > > There was general support to continue finessing this draft. If you have > > views on the above noted parameters, please make them known here. > > > > > > > > For reference: > > > > *Old waitlist policy* > > > > 1. Requester specifies smallest block they'd be willing to accept, > > equal to or larger than the applicable minimum size specified > elsewhere in > > ARIN policy. > > 2. Did not place a limit on the total existing IP address holdings of > > a party eligible for the waitlist. > > 3. Made resources issued from the waitlist ineligible for transfer > > until after a period of 12 months. > > > > *New Waitlist Policy* > > > > 1. Limits the size of block ARIN can issue on the waitlist to a /22. > > 2. Places a limit on the total existing IP address holdings of a party > > eligible for the waitlist at a /20 or less. > > 3. Makes resources issued from the waitlist ineligible for transfer > > until after a period of 60 months. > > > > > > Best, > > Alyssa > > > > > > > > On Thu, Mar 26, 2020 at 3:35 PM David Farmer <far...@umn.edu> wrote: > > > > I support this policy and believe the policy development process is the > > proper place to handle this issue. However, this policy seems to be > > implementable as a one-time policy directive to ARIN Staff. Once > > implemented, by putting the effected organizations back on the waiting > > list, it seems unnecessary to memorialized the text in the NRPM, it would > > immediately become extraneous and potentially confusing to future readers > > of the NRPM. > > > > > > > > Therefore, I would like to recommend the Policy Statement not be added to > > the NRPM upon its implementation. I believe this to be consistent with > the > > intent of the policy. Otherwise, does ARIN Staff have procedural advice > on > > how best to handle what seems like a one-time directive? > > > > > > > > Thanks > > > > > > > > On Tue, Mar 24, 2020 at 12:21 PM ARIN <i...@arin.net> wrote: > > > > > > Draft Policy ARIN-2020-2: Grandfathering of Organizations Removed from > > Waitlist by Implementation of ARIN-2019-16 > > > > Problem Statement: > > > > The implementation of the ARIN-2019-16 Advisory Council Recommendation > > Regarding NRPM 4.1.8: Unmet Requests caused some organizations to be > > removed from the waiting list that were approved under the old policy?s > > eligibility criteria. These organizations should have been grandfathered > > when the waitlist was reopened to allow them to receive an allocation of > > IPv4 up to the new policy?s maximum size constraint of a /22. > > > > Policy Statement: Update NRPM Section 4.1.8 as follows: > > > > Add section 4.1.8.3 (temporary language in the NRPM to remain until the > > policy objective is achieved) > > > > Restoring organizations to the waitlist > > > > ARIN will restore organizations that were removed from the waitlist at > > the adoption of ARIN-2019-16 to their previous position if their total > > holdings of IPv4 address space amounts to a /18 or less. The maximum > > size aggregate that a reinstated organization may qualify for is a /22. > > > > All restored organizations extend their 2 year approval by [number of > > months between July 2019 and implementation of new policy]. Any requests > > met through a transfer will be considered fulfilled and removed from the > > waiting list. > > > > Comments: > > > > Timetable for implementation: Immediate > > > > Anything Else: While attending ARIN 44 and discussing this with other > > community members the vast majority indicated that they agreed that some > > organizations were treated unfairly. This proposal is a remedy. > > _______________________________________________ > > ARIN-PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > > Unsubscribe or manage your mailing list subscription at: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact i...@arin.net if you experience any issues. > > > > > > > > > > -- > > > > =============================================== > > David Farmer Email:far...@umn.edu > > Networking & Telecommunication Services > > Office of Information Technology > > University of Minnesota > > 2218 University Ave SE Phone: 612-626-0815 > > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > > =============================================== > > > > _______________________________________________ > > ARIN-PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > > Unsubscribe or manage your mailing list subscription at: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact i...@arin.net if you experience any issues. > > > > _______________________________________________ > > ARIN-PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > > Unsubscribe or manage your mailing list subscription at: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact i...@arin.net if you experience any issues. > > > > _______________________________________________ > > ARIN-PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > > Unsubscribe or manage your mailing list subscription at: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact i...@arin.net if you experience any issues. > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.arin.net/pipermail/arin-ppml/attachments/20200717/29438be3/attachment.htm > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image001.png > Type: image/png > Size: 15673 bytes > Desc: not available > URL: < > https://lists.arin.net/pipermail/arin-ppml/attachments/20200717/29438be3/attachment.png > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML@arin.net > https://lists.arin.net/mailman/listinfo/arin-ppml > > > ------------------------------ > > End of ARIN-PPML Digest, Vol 181, Issue 20 > ****************************************** > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.