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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> wrote:
> On Mar 9, 2020, at 06:26 , ARIN <[email protected]
<mailto:[email protected]>> 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 ([email protected]
<mailto:[email protected]>).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] <mailto:[email protected]> if you
experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
