Makes sense to me. +1 On Thu, May 14, 2020 at 1:50 PM Mike Burns <m...@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-boun...@arin.net> *On Behalf Of *Chris > Woodfield > *Sent:* Thursday, May 14, 2020 1:40 PM > *To:* Owen DeLong <o...@delong.com>; ARIN-PPML List <arin-ppml@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 <o...@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 <scottleibr...@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 <o...@delong.com> wrote: > > I support this addition and support the policy with the addition. > > > > Owen > > > > > > On May 14, 2020, at 08:37, Fernando Frediani <fhfredi...@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 <takoka...@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 <o...@delong.com> wrote: > > > > > On Mar 9, 2020, at 06:26 , ARIN <i...@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@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net). > > Unsubscribe or manage your mailing list subscription at: > > https://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact i...@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@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.