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 > <mailto: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 >> <mailto: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 >>> >>> <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 >>> <mailto: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 >>> <mailto:o...@delong.com>> wrote: >>> >>> >>> > On Mar 9, 2020, at 06:26 , ARIN <i...@arin.net <mailto: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/ >>> > <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/ >>> > <https://www.arin.net/participate/policy/pdp/> >>> > >>> > Draft Policies and Proposals under discussion can be found at: >>> > https://www.arin.net/participate/policy/drafts/ >>> > <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 >>> <mailto:ARIN-PPML@arin.net>). >>> Unsubscribe or manage your mailing list subscription at: >>> https://lists.arin.net/mailman/listinfo/arin-ppml >>> <https://lists.arin.net/mailman/listinfo/arin-ppml> >>> Please contact i...@arin.net <mailto: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 >>> <mailto:ARIN-PPML@arin.net>). >>> Unsubscribe or manage your mailing list subscription at: >>> https://lists.arin.net/mailman/listinfo/arin-ppml >>> <https://lists.arin.net/mailman/listinfo/arin-ppml> >>> Please contact i...@arin.net <mailto: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 >> <mailto:ARIN-PPML@arin.net>). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> <https://lists.arin.net/mailman/listinfo/arin-ppml> >> Please contact i...@arin.net <mailto: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 > <mailto:ARIN-PPML@arin.net>). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > <https://lists.arin.net/mailman/listinfo/arin-ppml> > Please contact i...@arin.net <mailto: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.
