[arin-ppml] Revised and Reverted to Draft Policy - Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements

Thu May 14 15:58:49 EDT 2020

Makes sense to me. +1

On Thu, May 14, 2020 at 1:50 PM Mike Burns <mike at iptrading.com> wrote:

> I would support it with the removal of the pompous and meaningless word
> “summarily”.
>
> I like a clean NRPM.
>
>
>
> Regards,
> Mike
>
>
>
>
>
> *From:* ARIN-PPML <arin-ppml-bounces at arin.net> *On Behalf Of *Chris
> Woodfield
> *Sent:* Thursday, May 14, 2020 1:40 PM
> *To:* Owen DeLong <owen at delong.com>; ARIN-PPML List <arin-ppml at arin.net>
> *Subject:* Re: [arin-ppml] Revised and Reverted to Draft Policy - Draft
> Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
>
>
>
> I support as written, but agree that the word can be removed from the
> proposal without changing its intent, so happy to see it removed.
>
>
>
> -Chris
>
>
>
> On May 14, 2020, at 9:49 AM, Owen DeLong <owen at delong.com> wrote:
>
>
>
> I don’t construe it that way, but I have no objection to either of Scott’s
> suggestions, either.
>
>
>
> My concern is for the end effect of the proposed policy which is the same
> with any of the proposed wordings.
>
>
>
> Owen
>
>
>
>
>
> On May 14, 2020, at 09:10 , Scott Leibrand <scottleibrand at gmail.com>
> wrote:
>
>
>
> "Summarily" seems punitive, and doesn't seem necessary in this context.
> Perhaps just remove it and just leave "will be removed from the waitlist"?
> Or replace it with something like "immediately".
>
>
>
> -Scott
>
>
>
> On Thu, May 14, 2020 at 8:50 AM Owen DeLong <owen at delong.com> wrote:
>
> I support this addition and support the policy with the addition.
>
>
>
> Owen
>
>
>
>
>
> On May 14, 2020, at 08:37, Fernando Frediani <fhfrediani at gmail.com> wrote:
>
> 
>
> I support this proposal.
> It's fair to everybody and helps avoid fraud.
>
> Regards
> Fernando
>
> On 14/05/2020 11:56, Kat Hunter wrote:
>
> After making adjustments to the text, ARIN staff and legal conducted a new
> staff and legal review on 2019-1. You can view the updated review here:
> https://www.arin.net/participate/policy/drafts/2019_1/#staff-and-legal-review-30-april-2020 .
> It has been suggested that
>
> "It is worth noting that this Draft Policy does not include the removal of
> pending ARIN Waitlist requests for organizations that act as source
> organizations for 8.2, 8.3, or 8.4 transfers, which would allow them to
> conduct such transfers while waitlisted, and receive resources from the
> ARIN Waitlist immediately thereafter, as all organizations on the ARIN
> Waitlist have already applied, and are pending fulfillment.
>
> The text is clear and understandable, and can be implemented as written."
>
> After some discussion with some members of the AC, it was suggested that a
> new subsection is added to section 8 which would allow for additional
> clarity from this policy and some future cleanup via other future policy.
>
> "8.6 Waitlist Restrictions
>
> Any organization which is on the wait list and submits a request to be the
> source of a transfer under any provision in section 8 will be summarily
> removed from the wait list."
>
> I'd like to get the community's thoughts on the addition. With this
> addition, would you support the policy as written?
>
> -Kat Hunter
>
>
>
> On Tue, Mar 24, 2020 at 1:24 PM Kat Hunter <takokat81 at gmail.com> wrote:
>
> Owen, I think this is a good suggestion. I've updated the month
> designations in the other section to 90 days as, I agree, it is more
> precise when we are discussing shorter amounts of time. Additionally, I've
> taken your suggestion on wordsmithing that section and adjusted it just a
> little.
>
>
>
> " An organization which serves as the source of an 8.2 IPv4 transfer will
> not be allowed to apply for IPv4 address space under section 4.1.8 ARIN
> Waitlist for a period of 36 months following said transfer unless the
> recipient organization remains a subsidiary, parent company, or under
> common ownership with the source organization.".
>
>
>
> I wanted to make sure I specified that this was in reference to IPv4 and
> that the organization also remains a subsidiary, parent company, or under
> common ownership.  Thank you for the input. Additionally I'd like to see if
> there is anyone else that still supports or no longer longer supports this
> policy as written.
>
>
>
> Kat Hunter
>
>
>
> On Wed, Mar 11, 2020 at 4:42 AM Owen DeLong <owen at delong.com> wrote:
>
>
>
> > On Mar 9, 2020, at 06:26 , ARIN <info at arin.net> wrote:
> >
> > On 20 February 2020, the ARIN Advisory Council (AC) reverted the
> following Recommended Draft Policy to Draft Policy Status due to community
> feedback recommending significant substantive changes.:
> >
> > * Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
> >
> > The text has since been revised in response to that feedback.
> >
> > Revised text is below and can be found at:
> >
> > https://www.arin.net/participate/policy/drafts/2019_1/
> >
> > 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/participate/policy/pdp/
> >
> > Draft Policies and Proposals under discussion can be found at:
> > https://www.arin.net/participate/policy/drafts/
> >
> > Regards,
> >
> > Sean Hopkins
> > Policy Analyst
> > American Registry for Internet Numbers (ARIN)
> >
> >
> >
> >
> > Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
> >
> > Problem Statement:
> >
> > Per a recent ARIN Policy Experience Report and resulting AC discussion,
> it was noted that the language of Section 4.1.8 is imprecise in that it can
> be interpreted as specifying a waiting period for any allocation activity,
> as opposed to being intended to limit only the frequency of IPv4
> allocations under Section 4.
> >
> > The same Policy Experience Report also noted that ARIN staff has
> observed a pattern where an organization transfers space under NRPM Section
> 8.2 to a specified recipient, and then immediately applies for space under
> Section 4. This activity appears to be speculative in nature and not
> consistent with sound address management policy.
> >
> > The updated language in this proposal addresses the two issues above, as
> both concerns can be addressed via modifications to the same section and
> sentence thereof of the NRPM:
> >
> > Clarifies the waiting period to only prohibit requests for IPv4
> allocations under Section 4 of the NRPM
> > Disallows organizations that have transferred space to other parties
> within the past 36 months from applying for additional IPv4 space under
> NRPM Section 4.
> >
> > Policy Statement:
> >
> > Current language found in NRPM Section 4.1.8 - Unmet Requests:
> >
> > Repeated requests, in a manner that would circumvent 4.1.6, are not
> allowed: an organization currently on the waitlist must wait 90 days after
> receiving a distribution from the waitlist before applying for additional
> space. 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
> will also be advised of the availability of the transfer mechanism in
> section 8.3 as an alternative mechanism to obtain IPv4 addresses.
> >
> > Proposed new language 4.1.8:
> >
> > Multiple requests are not allowed: an organization currently on the
> waitlist must wait 90 days after receiving a distribution from the waitlist
> or IPv4 number resources as a recipient of any transfer before applying for
> additional space. 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 will also be advised of the availability of the transfer
> mechanism in section 8.3 as an alternative mechanism to obtain IPv4
> addresses.
> >
> > Restrictions apply for entities who have conducted recent resource
> transfers. These restrictions are specified in Section 8 for each relevant
> transfer category.
> >
> > Add the following under 8.2. Mergers, Acquisitions, and Reorganizations:
> >
> > After completion of an 8.2 transfer an organization may only apply for
> IPv4 address resources under Section 4.1.8. ARIN Waitlist if they have
> transferred IPv4 address resources under section 8.2 and the recipient
> organization is and remains a subsidiary, parent company, or an
> organization under common ownership of the same parent company as the
> organization that the IPv4 resources were transferred from. This
> restriction will last for 36 months and is applied to the organization that
> the IPv4 resources were transferred from and not the recipient.
>
> This paragraph cries out desperately for wordsmithing. It is very
> difficult to parse.
>
> Perhaps:
>
> An organization which serves as the source of an 8.2 transfer will not be
> allowed to apply for IPv4 address space under section 4.1.8 ARIN Waitlist
> for a period of 36 months following said transfer unless the recipient
> organization remains under common ownership with the source organization.
>
> > Add the following under 8.3. Transfers Between Specified Recipients
> Within the ARIN Region and under the Conditions on the source of the
> transfer:
> >
> > The source entity will not be allowed to apply for IPv4 address space
> under Section 4.1.8. ARIN Waitlist for a period of 36 months following the
> transfer of IPv4 address resources to another party.
> >
> > Under conditions on the recipient:
> >
> > If applicable the recipient will be removed from the ARIN Waitlist and
> will not be allowed to reapply under section 4.1.8. ARIN Waitlist for a
> period of 3 months.
>
> This should read “90 days” instead of “3 months” to retain consistency
> with 4.1.8.
>
> > Add the following under 8.4. Transfers Between Specified Recipients
> Within the ARIN Region and under the Conditions on the source of the
> transfer:
> >
> > The source entity will not be allowed to apply for IPv4 address space
> under Section 4.1.8. ARIN Waitlist for a period of 36 months following the
> transfer of IPv4 address resources to another party.
> >
> > Under conditions on the recipient:
> >
> > If applicable the recipient will be removed from the ARIN Waitlist and
> will not be allowed to reapply under section 4.1.8. ARIN Waitlist for a
> period of 3 months.
>
> This should read “90 days” instead of “3 months” to retain consistency
> with 4.1.8.
>
> >
> > Comments:
> >
> > This proposal incorporates two related policy goals, combined for
> convenience in one proposal as both can addressed via modification of the
> same section and sentence of the NRPM. During ARIN 43 it was proposed to
> the community that the two policy statements were severable, however, there
> was sufficient community support behind keeping both.
> >
> > There have been updates to section 4 since the beginning of the work on
> this policy. Text has been updated to reflect current NRPM.
> >
> > There was significant community support to change the word “repeated” as
> it was vague. Additionally, there was concerned that a company may perform
> an M&A transfer to itself/parent company and the original proposed language
> would exclude those companies from being able to apply to the waitlist.
> After the addition of the new merger and acquisition language, staff and
> legal recommended that the restrictions for applying to the waitlist for
> participants of the transfer market be added to the appropriate section in
> the Section 8 of the NRPM. Organizations should be informed of how their
> activities in the transfer market will impact them in reference to applying
> to the waitlist. These changes were to make it easier for staff and the
> community to understand these requirements.
>
> While I understand the desire to do this, I must point out that having the
> same rule specified in multiple places in the NRPM tends to lead to
> inconsistencies down the road.
>
> It is not at all unusual in this situation for a future policy proposal to
> miss one of these duplicate statements of the same rule and update only a
> subset of them. Even the above inconsistency in this proposal between 90
> days in section 4 and 3 months for the same thing twice in section 8 serves
> as an example of the perils of duplicating the same rule in multiple
> locations.
>
> I suggest, therefore, that instead of duplicating the rules, we reference
> section 4.1.8  in each of those cases as follows:
>
>         Recipients should be aware of the impact of transfers on their
> ability to apply and/or obtain space from the waitlist. These are spelled
> out in section 4.1.8.
>
> This provides clarity that there is an impact to be considered and clear
> guidance as to where to find that impact without abetting inconsistency.
>
> Owen
>
> _______________________________________________
> 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.
>
> _______________________________________________
> 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.
>
>
> _______________________________________________
> 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/20200514/765e0a02/attachment.htm>