[arin-ppml] Draft Policy ARIN-2020-2: Grandfathering of Organizations Removed from Waitlist by Implementation of ARIN-2019-16
Rudolph Daniel
rudi.daniel at gmail.com
Fri Jul 17 15:58:18 EDT 2020
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-request at arin.net> wrote:
> Send ARIN-PPML mailing list submissions to
> arin-ppml at 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-request at arin.net
>
> You can reach the person managing the list at
> arin-ppml-owner at 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 <owen at delong.com>
> To: Fernando Frediani <fhfrediani at gmail.com>
> Cc: arin-ppml at 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-CC2B5DB599AF at 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 <fhfrediani at 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
> >>
> >> sryerse at eclipse-networks.com | C: 770.656.1460
> >> 100 Ashford Center North | Suite 110 | Atlanta, Georgia 30338
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: ARIN-PPML <arin-ppml-bounces at arin.net> On Behalf Of Mike Burns
> >> Sent: Friday, July 17, 2020 10:59 AM
> >> To: hostmaster at uneedus.com; arin-ppml at 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-bounces at arin.net> On Behalf Of
> hostmaster at uneedus.com
> >> Sent: Thursday, July 16, 2020 7:59 AM
> >> To: arin-ppml at 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 <farmer at 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 <info at 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 at 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 info at arin.net if you experience any issues.
> >>>
> >>>
> >>>
> >>> --
> >>> ===============================================
> >>> David Farmer Email:farmer at 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 at 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 info at 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 at 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 info at 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 at 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 info at 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 at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> https://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at 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 at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 17 Jul 2020 10:25:35 -0700
> From: Chris Woodfield <chris at semihuman.com>
> To: john at egh.com
> Cc: arin-ppml <arin-ppml at 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-9EB882A39F0D at semihuman.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> > On Jul 16, 2020, at 11:06 AM, John Santos <john at 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 at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at 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 <bjones at vt.edu>
> To: Tom Pruitt <tpruitt at stratusnet.com>
> Cc: A N <anita.nikolich at gmail.com>, ARIN-PPML List
> <arin-ppml at 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+FHu4XWe8QRdHQOn83QmcHav39jFR1Km4FKbdrVueJb5Q at 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 <tpruitt at 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-bounces at arin.net> *On Behalf Of *A N
> > *Sent:* Friday, July 17, 2020 7:56 AM
> > *To:* ARIN-PPML List <arin-ppml at 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 <alyssa at 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 <farmer at 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 <info at 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 at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> >
> >
> >
> > --
> >
> > ===============================================
> > David Farmer Email:farmer at 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 at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at 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 at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at 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 at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at 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 at 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20200717/4297d5e9/attachment.htm>
More information about the ARIN-PPML
mailing list