[arin-ppml] draft policies 2009-1-2

Wed Mar 6 21:32:41 EST 2019

I support the intent of both policies.
Rudi Daniel

On Sun, Mar 3, 2019, 15:38 <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-2019-1: Clarify Section 4 IPv4 Request
>       Requirements (Chris Woodfield)
>    2. Re: Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request
>       Requirements (Scott Leibrand)
>    3. Re: Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request
>       Requirements (Joel Large)
>    4. Re: Draft Policy ARIN-2019-2: Waiting List Block Size
>       Restriction (Scott Leibrand)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 3 Mar 2019 10:02:35 -0800
> From: Chris Woodfield <chris at semihuman.com>
> To: Tom Fantacone <tom at iptrading.com>
> Cc: hostmaster <hostmaster at uneedus.com>, arin-ppml
>         <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2019-1: Clarify Section 4
>         IPv4 Request Requirements
> Message-ID: <1D353DEB-BDF2-45DD-B2FD-89E8C3690583 at semihuman.com>
> Content-Type: text/plain;       charset=utf-8
>
> Hi Tom - responses inline.
>
> One additional point - the current policy places a limit on how often an
> organization can receive resources from the waiting list. This draft
> changes the hold-down timer so that it now applies to *applications* for
> new allocations under the waiting list policy, not the receipt of resources
> from it.
>
> > On Mar 3, 2019, at 7:18 AM, Tom Fantacone <tom at iptrading.com> wrote:
> >
> > Chris,
> >
> > The "clarification" part of your proposal seems to be a no brainer (the
> waiting period is meant to apply to allocations only under section 4).  I
> assume ARIN staff is already interpreting it this way since that was the
> intent of the section.  So I wouldn't sever it unless the full policy
> doesn't gain support in which case we could revisit just inserting the
> clarification part.
> >
>
> That assumption is my understanding as well.
>
> > Regarding this:
> > "- Disallows organizations that have transferred space to other parties
> within the past 12 months from applying for additional IPv4 space under
> NRPM Section 4. "
> >
> > I want to make sure I understand it correctly.  If you transfer out
> space via 8.2/8.3/8.4, does this restriction mean you just can't receive
> space via the waiting list for 12 months, or via any mechanism (waiting
> list/transfer) for 12 months?  I think it means from the waiting list only,
> but want to be sure.
> >
>
> That is correct - note the phrase ?...under this section...? in the
> proposal text.
>
> Thanks,
>
> -Chris
>
>
> > Tom
> >
> >
> >
> > ---- On Sat, 02 Mar 2019 13:48:01 -0500 Chris Woodfield <
> chris at semihuman.com> wrote ----
> >
> > Speaking as the policy author, I?ll make two points:
> >
> > 1. I?m aware that given the other discussions around waiting list policy
> that are ongoing, this proposal may well be rendered moot by future policy
> changes. I still believe that this is worth pursuing as there?s a current
> need for clarification and increased disincentives for bad behavior today.
> > 2. I?m deliberately killing two not-terribly-related birds with one
> stone with this proposal, based on the fact that the two issues noted from
> the PER can be addressed by adding language to the same NRPM text. Happy to
> consider severing them if the community prefers.
> >
> > Thanks,
> >
> > -Chris
> >
> > > On Mar 2, 2019, at 9:33 AM, hostmaster at uneedus.com wrote:
> > >
> > > I think it is time to start the ball on the other policies.
> > >
> > > +1 on this. It seems focused on those gathering resources to resell.
> > >
> > > Albert Erdmann
> > > Network Administrator
> > > Paradise On Line Inc.
> > t info at arin.net if you experience any issues.
> >
> >
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 3 Mar 2019 10:52:41 -0800
> From: Scott Leibrand <scottleibrand at gmail.com>
> To: Chris Woodfield <chris at semihuman.com>
> Cc: Tom Fantacone <tom at iptrading.com>, arin-ppml <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2019-1: Clarify Section 4
>         IPv4 Request Requirements
> Message-ID: <056723A7-2403-4F03-A29C-DD5E3D610EF1 at gmail.com>
> Content-Type: text/plain;       charset=utf-8
>
> Thanks for clarifying that, Chris. I support this draft policy proposal:
> forcing applicants to wait to get into line for free space will at least
> slow down any attempts to make money off the free pool via the waiting
> list.
>
> Scott
>
> > On Mar 3, 2019, at 10:02 AM, Chris Woodfield <chris at semihuman.com>
> wrote:
> >
> > Hi Tom - responses inline.
> >
> > One additional point - the current policy places a limit on how often an
> organization can receive resources from the waiting list. This draft
> changes the hold-down timer so that it now applies to *applications* for
> new allocations under the waiting list policy, not the receipt of resources
> from it.
> >
> >> On Mar 3, 2019, at 7:18 AM, Tom Fantacone <tom at iptrading.com> wrote:
> >>
> >> Chris,
> >>
> >> The "clarification" part of your proposal seems to be a no brainer (the
> waiting period is meant to apply to allocations only under section 4).  I
> assume ARIN staff is already interpreting it this way since that was the
> intent of the section.  So I wouldn't sever it unless the full policy
> doesn't gain support in which case we could revisit just inserting the
> clarification part.
> >>
> >
> > That assumption is my understanding as well.
> >
> >> Regarding this:
> >> "- Disallows organizations that have transferred space to other parties
> within the past 12 months from applying for additional IPv4 space under
> NRPM Section 4. "
> >>
> >> I want to make sure I understand it correctly.  If you transfer out
> space via 8.2/8.3/8.4, does this restriction mean you just can't receive
> space via the waiting list for 12 months, or via any mechanism (waiting
> list/transfer) for 12 months?  I think it means from the waiting list only,
> but want to be sure.
> >>
> >
> > That is correct - note the phrase ?...under this section...? in the
> proposal text.
> >
> > Thanks,
> >
> > -Chris
> >
> >
> >> Tom
> >>
> >>
> >>
> >> ---- On Sat, 02 Mar 2019 13:48:01 -0500 Chris Woodfield <
> chris at semihuman.com> wrote ----
> >>
> >> Speaking as the policy author, I?ll make two points:
> >>
> >> 1. I?m aware that given the other discussions around waiting list
> policy that are ongoing, this proposal may well be rendered moot by future
> policy changes. I still believe that this is worth pursuing as there?s a
> current need for clarification and increased disincentives for bad behavior
> today.
> >> 2. I?m deliberately killing two not-terribly-related birds with one
> stone with this proposal, based on the fact that the two issues noted from
> the PER can be addressed by adding language to the same NRPM text. Happy to
> consider severing them if the community prefers.
> >>
> >> Thanks,
> >>
> >> -Chris
> >>
> >>> On Mar 2, 2019, at 9:33 AM, hostmaster at uneedus.com wrote:
> >>>
> >>> I think it is time to start the ball on the other policies.
> >>>
> >>> +1 on this. It seems focused on those gathering resources to resell.
> >>>
> >>> Albert Erdmann
> >>> Network Administrator
> >>> Paradise On Line Inc.
> >> t 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: 3
> Date: Sun, 03 Mar 2019 13:58:22 -0500
> From: Joel Large <jlarge at glwb.net>
> To: Scott Leibrand <scottleibrand at gmail.com>, Chris Woodfield
>         <chris at semihuman.com>
> Cc: arin-ppml <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2019-1: Clarify Section 4
>         IPv4 Request Requirements
> Message-ID: <20190303185829.2313F1042C74 at smtp1.arin.net>
> Content-Type: text/plain; charset="utf-8"
>
> I agree anything to curb this practice.? The fact we are asked to justify
> the need for the IPV4 space and people are getting them falsely needing
> them is frustrating.?Joel LargeGeneral ManagerGLW Broadband Inc.440 926
> 3230Sent from my Verizon, Samsung Galaxy smartphone
> -------- Original message --------From: Scott Leibrand <
> scottleibrand at gmail.com> Date: 3/3/19  1:52 PM  (GMT-05:00) To: Chris
> Woodfield <chris at semihuman.com> Cc: arin-ppml <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2019-1: Clarify Section 4 IPv4
> ? Request Requirements Thanks for clarifying that, Chris. I support this
> draft policy proposal: forcing applicants to wait to get into line for free
> space will at least slow down any attempts to make money off the free pool
> via the waiting list. Scott> On Mar 3, 2019, at 10:02 AM, Chris Woodfield <
> chris at semihuman.com> wrote:> > Hi Tom - responses inline.> > One
> additional point - the current policy places a limit on how often an
> organization can receive resources from the waiting list. This draft
> changes the hold-down timer so that it now applies to *applications* for
> new allocations under the waiting list policy, not the receipt of resources
> from it.> >> On Mar 3, 2019, at 7:18 AM, Tom Fantacone <tom at iptrading.com>
> wrote:>> >> Chris,>> >> The "clarification" part of your proposal seems to
> be a no brainer (the waiting period is meant to apply to allocations only
> under section 4).? I assume ARIN staff is already interpreting it this way
> since that was the intent of the section
>  .? So I wouldn't sever it unless the full policy doesn't gain support in
> which case we could revisit just inserting the clarification part.>> > >
> That assumption is my understanding as well.> >> Regarding this:>> "-
> Disallows organizations that have transferred space to other parties within
> the past 12 months from applying for additional IPv4 space under NRPM
> Section 4. ">> >> I want to make sure I understand it correctly.? If you
> transfer out space via 8.2/8.3/8.4, does this restriction mean you just
> can't receive space via the waiting list for 12 months, or via any
> mechanism (waiting list/transfer) for 12 months?? I think it means from the
> waiting list only, but want to be sure.>> > > That is correct - note the
> phrase ?...under this section...? in the proposal text. > > Thanks,> >
> -Chris> > >> Tom>> >> >> >> ---- On Sat, 02 Mar 2019 13:48:01 -0500 Chris
> Woodfield <chris at semihuman.com> wrote ---->> >> Speaking as the policy
> author, I?ll make two points:>> >> 1. I?m aware th
>  at given the other discussions around waiting list policy that are
> ongoing, this proposal may well be rendered moot by future policy changes.
> I still believe that this is worth pursuing as there?s a current need for
> clarification and increased disincentives for bad behavior today.>> 2. I?m
> deliberately killing two not-terribly-related birds with one stone with
> this proposal, based on the fact that the two issues noted from the PER can
> be addressed by adding language to the same NRPM text. Happy to consider
> severing them if the community prefers.>> >> Thanks,>> >> -Chris>> >>> On
> Mar 2, 2019, at 9:33 AM, hostmaster at uneedus.com wrote:>>> >>> I think it
> is time to start the ball on the other policies.>>> >>> +1 on this. It
> seems focused on those gathering resources to resell.>>> >>> Albert
> Erdmann>>> Network Administrator>>> Paradise On Line Inc.>> t
> info at arin.net if you experience any issues.>> >> > >
> _______________________________________________> ARIN-PPML> You are receivin
>  g 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-PPMLYou are
> receiving this message because you are subscribed tothe 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-ppmlPlease
> 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/20190303/3e53098c/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Sun, 3 Mar 2019 11:37:42 -0800
> From: Scott Leibrand <scottleibrand at gmail.com>
> To: ARIN <info at arin.net>
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2019-2: Waiting List Block
>         Size Restriction
> Message-ID: <F8BAF292-CD8B-4379-A119-24120A11D116 at gmail.com>
> Content-Type: text/plain;       charset=utf-8
>
> I support Draft Policy ARIN-2019-2. IMO limiting waiting list recipients
> to a /22 is a reasonable approach that somewhat reduces the gains for
> fraudulent activity, and ensures that ARIN can serve more legitimate
> requests for each block it reclaims/receives. Organizations needing more
> than a /22 should be getting it from the transfer market anyway, so I don?t
> see much downside to such a restriction on waiting list allocations.
>
> Scott
>
> > On Feb 26, 2019, at 9:49 AM, ARIN <info at arin.net> wrote:
> >
> > On 21 February 2019, the ARIN Advisory Council (AC) accepted
> "ARIN-prop-261: Waiting List Block Size Restriction" as a Draft Policy.
> >
> > Draft Policy ARIN-2019-2 is below and can be found at:
> > https://www.arin.net/policy/proposals/2019_2.html
> >
> > You are encouraged to discuss all Draft Policies on PPML. The AC will
> evaluate the discussion in order to assess the conformance of this draft
> policy with ARIN's Principles of Internet number resource policy as stated
> in the Policy Development Process (PDP). Specifically, these principles are:
> >
> > * Enabling Fair and Impartial Number Resource Administration
> > * Technically Sound
> > * Supported by the Community
> >
> > The PDP can be found at:
> > https://www.arin.net/policy/pdp.html
> >
> > Draft Policies and Proposals under discussion can be found at:
> > https://www.arin.net/policy/proposals/index.html
> >
> > Regards,
> >
> > Sean Hopkins
> > Policy Analyst
> > American Registry for Internet Numbers (ARIN)
> >
> >
> >
> > Draft Policy ARIN-2019-2: Waiting List Block Size Restriction
> >
> > Problem Statement:
> >
> > A substantial amount of misuse of the waiting list is suspected by ARIN
> staff. A significant percentage of organizations that receive blocks from
> the waiting list subsequently issue these blocks to other organizations via
> 8.3 or 8.4 transfers shortly after the one year waiting period required
> before engaging in such outbound transfers. Most of these cases involve
> larger-sized blocks, and many involve organizations that already have large
> IPv4 holdings. Some organizations engage in this practice multiple times,
> rejoining the waiting list shortly after transferring out blocks previously
> received on the waiting list. There are even cases of multiple startup
> organizations requesting approval to be placed on the waiting list where
> these organizations' requests can all be tracked originating from the same
> IP address. While it is possible that some of these cases are legitimate,
> and while it is difficult for ARIN to prove fraud in most individual cases,
> the large number of cases l
>  ike these indicates a high likelihood that there is significant misuse of
> the waiting list. Specifically, some organizations are likely being
> dishonest in projecting their need for IPv4 space with the intent of
> receiving blocks off the waiting list so that they can sell them one year
> after receiving them. In the case of multiple startups, some organizations
> that receive blocks on the waiting list subsequently perform a 8.2
> merger/acquisition, allowing them to sell the blocks even before the one
> year waiting period.
> >
> > The problem is serious enough that the ARIN Board of Trustees has
> suspended issuance of number resources while a solution to this problem is
> found, and it is unfair to organizations with legitimate need on the
> waiting list that they are being crowded out and delayed by those looking
> to game the system.
> >
> > Policy Statement:
> >
> > Actual Text:
> >
> > 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 qualified for and the
> smallest block size acceptable.
> >
> > New Text:
> >
> > 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 qualified for or a
> /22, whichever is smaller, and the smallest block size acceptable, not to
> exceed a /22.
> >
> > Comments:
> >
> > Timeframe for Implementation: Immediate
> >
> > Anything Else: By limiting the maximum block size for waiting list
> recipients to a /22, the financial incentive to misuse the waiting list to
> receive blocks with the intent to sell them will be drastically reduced.
> The majority of waiting list requests are for smaller block sizes, and
> these requests will be more readily met as the abusers will no longer be
> crowding out the legitimate organizations with need. The original intent of
> the waiting list to help smaller organizations and new entrants will be
> realized. RIPE, APNIC and LACNIC do not have waiting lists, but they each
> have an emergency pool geared toward new recipients with a /22 limit which
> has largely curtailed abuse. Organizations that genuinely qualify for
> larger blocks can still obtain these in the marketplace through 8.3
> transfers.
> > _______________________________________________
> > 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.
>
>
> ------------------------------
>
> 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 165, Issue 15
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190306/0e8dd5ec/attachment.htm>