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 
<mailto: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 
<mailto: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
 . 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/
> 
> 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 
<mailto: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 <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
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
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
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
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
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.

Reply via email to