[arin-ppml] ARIN-PPML Digest, Vol 167, Issue 80

[Michael Williams]

I’m fine increasing the wait list time with a larger size allocation such
as a /21.

Michael

Sent from my iPhone

On 12 May 2019, at 14:10, David Farmer <farmer at umn.edu> wrote:

With the current policy, as proposed by the AC's response, as long as you
have less than a total of three /22s or less direct resources, you could
get up to two additional /22s but not a /21 all at once. Note if you have
no direct resources at all, you can get up to 5 /22s over a time of at
least a year and a quarter plus the wait time on the list.

Smaller blocks over time seem fairer as it allows more entities a bit at
the apple. We could allow /21s instead of /22s but then we should probably
extend the time before you can get back on the list to 6 months.

it would be good to hear from more people on these issues.

On Sun, May 12, 2019 at 10:55 AM Christian Lefrançois <
clefranc at diffusionfermont.ca> wrote:

> Hi all,
> I agree with Michael Williams, I'm in the same situation, and on the
> waiting
> list for more than a year. I need a /21, to finally be free of upstream
> providers fees for IPv4 addresses (lease). I'll gladly give back all
> resources to ARIN in the eventuality of end of business, or if I can manage
> to switch completely to IPv6. Not interested with the IPv4 black market.
>
> I'm in charge of a very small coop cable operator, my market is about 1900
> customers, we're hooking members as fast as possible, will reach (and
> surpass) /22 in a few months. So, in my perspective, /21 should be the
> maximum.
>
> Christian Lefrançois
> Diffusion Fermont
>
> -----Message d'origine-----
> De : ARIN-PPML <arin-ppml-bounces at arin.net> De la part de
> arin-ppml-request at arin.net
> Envoyé : 10 mai 2019 18:33
> À : arin-ppml at arin.net
> Objet : ARIN-PPML Digest, Vol 167, Issue 80
>
> 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: Fwd: Advisory Council Recommendation Regarding NRPM
>       4.1.8. Unmet Requests (Scott Leibrand)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 10 May 2019 15:32:17 -0700
> From: Scott Leibrand <scottleibrand at gmail.com>
> To: Michael Williams <michael.williams at glexia.com>
> Cc: Kevin Blumberg <kevinb at thewire.ca>, "arin-ppml at arin.net"
>         <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Fwd: Advisory Council Recommendation
>         Regarding NRPM 4.1.8. Unmet Requests
> Message-ID:
>         <CAGkMwz5Bhp=SLVipZtx=fpu9ni2_uk_L3Tt1=
> 5Lb3x5rNPQJtg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> There are organizations of all sizes with direct unmet needs for address
> blocks of all sizes up to /16 or larger.  The waitlist is *not* intended to
> meet all such requests: it simply can't be done, because the free pool is
> empty, and there is way more demand than supply at a price of ~$0.  Rather,
> the waitlist is intended to make sure that returned/reclaimed addresses are
> not stuck at ARIN, but rather distributed in a way that serves a useful
> purpose.
>
> Organizations that need large blocks of address space should be going to
> the
> market to acquire them, and transferring them to meet their justified need.
> Some organizations that need smaller blocks of addresses, but not urgently,
> can try to get them via the waitlist.  But the more larger allocations we
> allow from reclaimed space, the fewer such organizations can be served, and
> the longer they'll need to wait.  So it makes sense to me to have a
> relatively stringent maximum wait list allocation, particularly since that
> also reduces the financial reward to fraudulent actors and/or those
> attempting to game the system.
>
> So I support this policy, including the /22 maximum.
>
> -Scott (representing only myself)
>
> On Fri, May 10, 2019 at 3:19 PM Michael Williams <
> michael.williams at glexia.com> wrote:
>
> > Representing ARIN member organisation GLEXI-3 *I do not support* the
> > policy as written. Maximum wait list allocation should be at least a /21.
> > We have a direct unmet need for a /21 right now.
> >
> > My argument is if an organisation receives an allocation from the wait
> > list they should have to return that allocation directly to ARIN if
> > not used. There should be no organisation to organisation transfer
> > allowed for IP allocations received from the wait list. That?d
> > eliminate all these crazy /16 allocation sales that we see now.
> >
> > Regards,
> >
> > Michael
> >
> > Sent from my iPhone
> >
> > On 10 May 2019, at 17:36, Kevin Blumberg <kevinb at thewire.ca> wrote:
> >
> > David,
> >
> >
> >
> > I would rather see a limit or delay on the number of times an
> > organization can go back to the waitlist than prevent organizations
> > from getting any space from the wait list.
> >
> >
> >
> > Would I be more supportive if the number was larger? I don?t believe
> > that is the right control mechanism, so no.
> >
> >
> >
> > Limiting the size to a /22 was a way of distributing fairly to as many
> > organizations as possible and limiting the abuse vector.
> >
> >
> >
> > Thanks,
> >
> > Kevin
> >
> >
> >
> >
> >
> > *From:* ARIN-PPML <arin-ppml-bounces at arin.net> *On Behalf Of *David
> > Farmer
> > *Sent:* Friday, May 10, 2019 4:44 PM
> > *To:* Tom Pruitt <tpruitt at stratusnet.com>
> > *Cc:* arin-ppml at arin.net
> > *Subject:* Re: [arin-ppml] Fwd: Advisory Council Recommendation
> > Regarding NRPM 4.1.8. Unmet Requests
> >
> >
> >
> > If /20 is too small is their another size you would propose? a /19 or
> > a
> > /18 maybe? Do you have an argument for why that is the right number?
> >
> >
> >
> > When the AC looked at this there was strong support for limiting the
> > size of the organization that could qualify to ensure these resources
> > went to smaller organizations. But there were varying opinions on what
> > that size should be, /20 was just the option with the most support
> amongst
> the AC.
> >
> >
> >
> > This formulation also provides a limit on how many times an
> > organization can go back to the waiting list, allowing smaller
> > organizations more times to return to the waiting list, while limiting
> > lager organization to fewer times to return to the waiting list.  And
> > organizations that already have more than a /20 must go to the market.
> >
> >
> >
> > A /20 limit, gives a new organization (with no resources) the
> > opportunity receive up to 5 allocations from the waiting list if they
> > got a /22 each time.
> >
> > A /19 limit would allow a new ISP up to 9 allocations if they got a
> > /22 each time.
> >
> > A /18 limit would allow a new ISP up to 17 allocations if they got a
> > /22 each time.
> >
> >
> >
> > Please realize the waiting list is primarily a mechanism to ensure
> > resources are not stuck at ARIN, it should not be seen as a reliable
> > means of obtaining resources.
> >
> >
> >
> > Thanks
> >
> >
> >
> > On Fri, May 10, 2019 at 2:45 PM Tom Pruitt <tpruitt at stratusnet.com>
> wrote:
> >
> > I do not support the new text, specifically the  limit of a /20 per
> > organization.
> >
> >
> >
> > The limiting of an organization to an aggregate of a /20 is a huge
> > hinderance of the ability of a smaller ISP to compete.  A smaller ISP
> > that can win business on service and cost could lose that same business
> due to
> > simply recouping the IPv4 costs.   Large ISPs will often give the IPs
> away
> > to win the business, and it costs them nothing as they received their
> IPV4
> > space for free.   Additionally, many smaller ISPs operate in outlying
> areas
> > where IPv6 adoption will likely be slow, which will also hinder their
> > ability to push IPv6.    I?m not sure at what point an organization
> becomes
> > ?large?, but the smaller organizations are the ones that will be hurt
> > by this limit.
> >
> >
> >
> > What happens to organizations that are currently on the wait list that
> > have an aggregate of a /20 or more?  Do they still get  a /22.  Some of
> > those organizations have been on the list for over a year.   Assuming
> they
> > played by the rules and made decisions based on the assumption that
> > they would get an allotment of IPv4 addresses, denying them any
> > addresses after they have waited a year or more could be very
> > detrimental to them. These policy changes and decisions affect the
> > smaller entities greatly, and they need some clarity.
> >
> >
> >
> >
> >
> >
> >
> > Thanks,
> >
> > Tom Pruitt
> >
> > Network Engineer
> >
> > Stratus Networks
> >
> >
> >
> > <image002.png>
> >
> >
> >
> > *From:* ARIN-PPML <arin-ppml-bounces at arin.net> *On Behalf Of *Andrew
> > Dul
> > *Sent:* Monday, May 6, 2019 4:09 PM
> > *To:* arin-ppml at arin.net
> > *Subject:* [arin-ppml] Fwd: Advisory Council Recommendation Regarding
> > NRPM 4.1.8. Unmet Requests
> >
> >
> >
> > Hello,
> >
> > I'd like to bring your attention to another issue that may have been
> > lost in the flurry of other emails.  We are currently in a 14 day
> > feedback period for the AC's response to the Board's suspension of the
> wait-list.
> > Please note the following updated text for the wait-list.  Your
> > comments on this updated text are welcome.
> >
> > Thanks,
> >
> > Andrew
> >
> >
> >
> > ===
> >
> > If no such block is available, the organization will be provided the
> > option to be placed on a waiting list of pre-qualified recipients,
> > listing both the block size, for which the organization is qualified,
> > which in the case of the waiting list shall not be larger than a /22,
> > and the smallest block size acceptable to the organization. An
> > organization may not be added to the waiting list if it already holds
> > IPv4 resources amounting in aggregate to more than a /20 of address
> > space. Resources received via section 4.1.8 may not be transferred within
> 60 months of the issuance date.
> >
> >
> >
> > -------- Forwarded Message --------
> >
> > *Subject: *
> >
> > [arin-ppml] Advisory Council Recommendation Regarding NRPM 4.1.8.
> > Unmet Requests
> >
> > *Date: *
> >
> > Mon, 29 Apr 2019 11:16:31 -0400
> >
> > *From: *
> >
> > ARIN <info at arin.net> <info at arin.net>
> >
> > *To: *
> >
> > arin-ppml at arin.net
> >
> >
> >
> > Subject:
> >
> > At their 16 January Meeting, the Board of Trustees suspended issuance
> > of number resources under NRPM section 4.1.8.2. (Fulfilling Unmet
> > Needs), and referred NRPM section 4.1.8 to the ARIN Advisory Council
> > for their recommendation.
> >
> > The Advisory Council has provided its recommendation, and per ARIN's
> > Policy Development Process, the recommendation is hereby submitted to
> > the Public Policy Mailing List for a community discussion period of 14
> > days, to conclude on 13 May.
> >
> > Once completed, the Board of Trustees will review the AC?s
> > recommendation and the PPML discussion.
> >
> > The full text of the Advisory Council's recommendation is below.
> >
> > Board of Trustees meeting minutes are available at:
> >
> > https://www.arin.net/about/welcome/board/meetings/2019_0116/
> >
> > For more details on the Policy Development Process, visit:
> >
> > https://www.arin.net/participate/policy/pdp/
> >
> > Regards,
> >
> > Sean Hopkins
> > Policy Analyst
> > American Registry for Internet Numbers (ARIN)
> >
> >
> >
> > Advisory Council recommendation:
> >
> > In accordance with section 10.2 of the ARIN Policy Development
> > Process, the ARIN Advisory Council recommends the following actions to
> > the Board of Trustees in response to the Board?s suspension of part of
> > the operation of sections 4.1.8, 4.1.8.1 and 4.1.8.2 of the Numbering
> Resource Policy Manual:
> >
> > Replace section 4.1.8 as follows, then reinstate the full operation of
> > sections 4.1.8, 4.1.8.1 and 4.1.8.2 immediately.
> >
> > 4.1.8. Unmet Requests
> >
> > In the event that ARIN does not have a contiguous block of addresses
> > of sufficient size to fulfill a qualified request, ARIN will provide
> > the requesting organization with the option to specify the smallest
> > block size they?d be willing to accept, equal to or larger than the
> > applicable minimum size specified elsewhere in ARIN policy. If such a
> > smaller block is available, ARIN will fulfill the request with the
> > largest single block available that fulfills the request.
> >
> > If no such block is available, the organization will be provided the
> > option to be placed on a waiting list of pre-qualified recipients,
> > listing both the block size, for which the organization is qualified,
> > which in the case of the waiting list shall not be larger than a /22,
> > and the smallest block size acceptable to the organization. An
> > organization may not be added to the waiting list if it already holds
> > IPv4 resources amounting in aggregate to more than a /20 of address
> > space. Resources received via section 4.1.8 may not be transferred within
> 60 months of the issuance date.
> >
> > Repeated requests, in a manner that would circumvent 4.1.6, are not
> > allowed: an organization may only receive one allocation, assignment,
> > or transfer every 3 months, but ARIN, at its sole discretion, may
> > waive this requirement if the requester can document a change in
> > circumstances since their last request that could not have been
> > reasonably foreseen at the time of the original request, and which now
> justifies additional space.
> > Qualified requesters whose request cannot be immediately met will also
> > be advised of the availability of the transfer mechanism in section
> > 8.3 as an alternative mechanism to obtain IPv4 addresses.
> > _______________________________________________
> > 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.
> >
> >
> >
> >
> > --
> >
> > ===============================================
> > 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.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <
> https://lists.arin.net/pipermail/arin-ppml/attachments/20190510/fd735392/at
> tachment.html
> <https://lists.arin.net/pipermail/arin-ppml/attachments/20190510/fd735392/attachment.html>
> >
>
> ------------------------------
>
> 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 167, Issue 80
> ******************************************
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190512/e38c87a4/attachment.htm>