I have seen proposals in different RIRs from /23 to /20 and to be honest I believe that /22 is fine for newcomers or to a maximum or as a maximum an existing one. /23 is way too small and almost useless to most cases. Even /22 are not much addresses but enough for someone to exist in the Internet and do a proper CGNAT or similar techniques in order to have a proper Dual-Stack.

Anything that comes back into the pool should always favor newcomers or those who haven't reached a /22 yet. To be honest I don't see much sense for a newcomer ISP not to receive a /22 straight upon first request. Being an ISP is already justification to receive a /22.

Anything beyond that should happen via transfers for existing members.

Fernando

On 12/05/2019 15:16, Michael Williams wrote:
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 <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> 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 <[email protected]
    <mailto:[email protected]>> De la part de
    [email protected] <mailto:[email protected]>
    Envoyé : 10 mai 2019 18:33
    À : [email protected] <mailto:[email protected]>
    Objet : ARIN-PPML Digest, Vol 167, Issue 80

    Send ARIN-PPML mailing list submissions to
    [email protected] <mailto:[email protected]>

    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
    [email protected] <mailto:[email protected]>

    You can reach the person managing the list at
    [email protected] <mailto:[email protected]>

    When replying, please edit your Subject line so it is more
    specific than
    "Re: Contents of ARIN-PPML digest..."


    Today's Topics:

       1. 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 <[email protected]
    <mailto:[email protected]>>
    To: Michael Williams <[email protected]
    <mailto:[email protected]>>
    Cc: Kevin Blumberg <[email protected]
    <mailto:[email protected]>>, "[email protected]
    <mailto:[email protected]>"
            <[email protected] <mailto:[email protected]>>
    Subject: Re: [arin-ppml] Fwd: Advisory Council Recommendation
            Regarding NRPM 4.1.8. Unmet Requests
    Message-ID:
           
    <CAGkMwz5Bhp=SLVipZtx=fpu9ni2_uk_L3Tt1=5lb3x5rnpq...@mail.gmail.com
    <mailto:[email protected]>>
    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 <
    [email protected] <mailto:[email protected]>>
    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 <[email protected]
    <mailto:[email protected]>> 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 <[email protected]
    <mailto:[email protected]>> *On Behalf Of *David
    > Farmer
    > *Sent:* Friday, May 10, 2019 4:44 PM
    > *To:* Tom Pruitt <[email protected]
    <mailto:[email protected]>>
    > *Cc:* [email protected] <mailto:[email protected]>
    > *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
    <[email protected] <mailto:[email protected]>> 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 <[email protected]
    <mailto:[email protected]>> *On Behalf Of *Andrew
    > Dul
    > *Sent:* Monday, May 6, 2019 4:09 PM
    > *To:* [email protected] <mailto:[email protected]>
    > *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 <[email protected] <mailto:[email protected]>> <[email protected]
    <mailto:[email protected]>>
    >
    > *To: *
    >
    > [email protected] <mailto:[email protected]>
    >
    >
    >
    > 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 ([email protected]
    <mailto:[email protected]>).
    > Unsubscribe or manage your mailing list subscription at:
    > https://lists.arin.net/mailman/listinfo/arin-ppml
    > Please contact [email protected] <mailto:[email protected]> if you
    experience any issues.
    >
    > _______________________________________________
    > ARIN-PPML
    > You are receiving this message because you are subscribed to
    the ARIN
    > Public Policy Mailing List ([email protected]
    <mailto:[email protected]>).
    > Unsubscribe or manage your mailing list subscription at:
    > https://lists.arin.net/mailman/listinfo/arin-ppml
    > Please contact [email protected] <mailto:[email protected]> if you
    experience any issues.
    >
    >
    >
    >
    > --
    >
    > ===============================================
    > David Farmer Email:[email protected] <mailto:email%[email protected]>
    > 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 ([email protected]
    <mailto:[email protected]>).
    > Unsubscribe or manage your mailing list subscription at:
    > https://lists.arin.net/mailman/listinfo/arin-ppml
    > Please contact [email protected] <mailto:[email protected]> if you
    experience any issues.
    >
    > _______________________________________________
    > ARIN-PPML
    > You are receiving this message because you are subscribed to
    the ARIN
    > Public Policy Mailing List ([email protected]
    <mailto:[email protected]>).
    > Unsubscribe or manage your mailing list subscription at:
    > https://lists.arin.net/mailman/listinfo/arin-ppml
    > Please contact [email protected] <mailto:[email protected]> if you
    experience any issues.
    >
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL:
    <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
    [email protected] <mailto:[email protected]>
    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 ([email protected]
    <mailto:[email protected]>).
    Unsubscribe or manage your mailing list subscription at:
    https://lists.arin.net/mailman/listinfo/arin-ppml
    Please contact [email protected] <mailto:[email protected]> if you
    experience any issues.



--
===============================================
David Farmer Email:[email protected] <mailto:email%[email protected]>
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 ([email protected] <mailto:[email protected]>).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] <mailto:[email protected]> if you experience any issues.

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

Reply via email to