<div dir="ltr"><div class="gmail_default" style="font-size:small">I support this proposal as written.<br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>—<br>Brian<br></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 14, 2020 at 10:56 AM Kat Hunter <<a href="mailto:takokat81@gmail.com">takokat81@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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: <a href="https://www.arin.net/participate/policy/drafts/2019_1/#staff-and-legal-review-30-april-2020" target="_blank">https://www.arin.net/participate/policy/drafts/2019_1/#staff-and-legal-review-30-april-2020</a> . It has been suggested that <div>"<span style="color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,"segoe ui",Roboto,"helvetica neue",Arial,"noto sans",sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol","noto color emoji"">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.</span></div><p style="box-sizing:border-box;margin-top:0px;margin-bottom:1rem;line-height:1.5;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,"segoe ui",Roboto,"helvetica neue",Arial,"noto sans",sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol","noto color emoji"">The text is clear and understandable, and can be implemented as written."</p><p style="box-sizing:border-box;margin-top:0px;margin-bottom:1rem;line-height:1.5;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,"segoe ui",Roboto,"helvetica neue",Arial,"noto sans",sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol","noto color emoji"">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.</p><p style="box-sizing:border-box;margin-top:0px;margin-bottom:1rem;line-height:1.5;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,"segoe ui",Roboto,"helvetica neue",Arial,"noto sans",sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol","noto color emoji"">"8.6 Waitlist Restrictions</p><p style="box-sizing:border-box;margin-top:0px;margin-bottom:1rem;line-height:1.5;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,"segoe ui",Roboto,"helvetica neue",Arial,"noto sans",sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol","noto color emoji"">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."</p><p style="box-sizing:border-box;margin-top:0px;margin-bottom:1rem;line-height:1.5;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,"segoe ui",Roboto,"helvetica neue",Arial,"noto sans",sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol","noto color emoji"">I'd like to get the community's thoughts on the addition. With this addition, would you support the policy as written? </p><p style="box-sizing:border-box;margin-top:0px;margin-bottom:1rem;line-height:1.5;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,"segoe ui",Roboto,"helvetica neue",Arial,"noto sans",sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol","noto color emoji"">-Kat Hunter</p></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 24, 2020 at 1:24 PM Kat Hunter <<a href="mailto:takokat81@gmail.com" target="_blank">takokat81@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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. <div><br></div><div>"

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.". </div><div><br></div><div>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.</div><div><br></div><div>Kat Hunter</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 11, 2020 at 4:42 AM Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Mar 9, 2020, at 06:26 , ARIN <<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>> wrote:<br>
> <br>
> 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.:<br>
> <br>
> * Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements<br>
> <br>
> The text has since been revised in response to that feedback.<br>
> <br>
> Revised text is below and can be found at:<br>
> <br>
> <a href="https://www.arin.net/participate/policy/drafts/2019_1/" rel="noreferrer" target="_blank">https://www.arin.net/participate/policy/drafts/2019_1/</a><br>
> <br>
> 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:<br>
> <br>
> * Enabling Fair and Impartial Number Resource Administration<br>
> * Technically Sound<br>
> * Supported by the Community<br>
> <br>
> The PDP can be found at:<br>
> <a href="https://www.arin.net/participate/policy/pdp/" rel="noreferrer" target="_blank">https://www.arin.net/participate/policy/pdp/</a><br>
> <br>
> Draft Policies and Proposals under discussion can be found at:<br>
> <a href="https://www.arin.net/participate/policy/drafts/" rel="noreferrer" target="_blank">https://www.arin.net/participate/policy/drafts/</a><br>
> <br>
> Regards,<br>
> <br>
> Sean Hopkins<br>
> Policy Analyst<br>
> American Registry for Internet Numbers (ARIN)<br>
> <br>
> <br>
> <br>
> <br>
> Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements<br>
> <br>
> Problem Statement:<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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:<br>
> <br>
> Clarifies the waiting period to only prohibit requests for IPv4 allocations under Section 4 of the NRPM<br>
> Disallows organizations that have transferred space to other parties within the past 36 months from applying for additional IPv4 space under NRPM Section 4.<br>
> <br>
> Policy Statement:<br>
> <br>
> Current language found in NRPM Section 4.1.8 - Unmet Requests:<br>
> <br>
> 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.<br>
> <br>
> Proposed new language 4.1.8:<br>
> <br>
> 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.<br>
> <br>
> Restrictions apply for entities who have conducted recent resource transfers. These restrictions are specified in Section 8 for each relevant transfer category.<br>
> <br>
> Add the following under 8.2. Mergers, Acquisitions, and Reorganizations:<br>
> <br>
> 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.<br>
<br>
This paragraph cries out desperately for wordsmithing. It is very difficult to parse.<br>
<br>
Perhaps:<br>
<br>
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.<br>
<br>
> Add the following under 8.3. Transfers Between Specified Recipients Within the ARIN Region and under the Conditions on the source of the transfer:<br>
> <br>
> 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.<br>
> <br>
> Under conditions on the recipient:<br>
> <br>
> 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.<br>
<br>
This should read “90 days” instead of “3 months” to retain consistency with 4.1.8.<br>
<br>
> Add the following under 8.4. Transfers Between Specified Recipients Within the ARIN Region and under the Conditions on the source of the transfer:<br>
> <br>
> 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.<br>
> <br>
> Under conditions on the recipient:<br>
> <br>
> 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.<br>
<br>
This should read “90 days” instead of “3 months” to retain consistency with 4.1.8.<br>
<br>
> <br>
> Comments:<br>
> <br>
> 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.<br>
> <br>
> There have been updates to section 4 since the beginning of the work on this policy. Text has been updated to reflect current NRPM.<br>
> <br>
> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I suggest, therefore, that instead of duplicating the rules, we reference section 4.1.8  in each of those cases as follows:<br>
<br>
        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.<br>
<br>
This provides clarity that there is an impact to be considered and clear guidance as to where to find that impact without abetting inconsistency.<br>
<br>
Owen<br>
<br>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div>