<div dir="ltr">Ok, I think I understand what you're concerned about. But I think that's a different issue, which isn't caused by a conflict with the NRPM, but rather is caused by ARIN's operational practice (correct me if I'm wrong, John) of requiring 50% utilization of acquired space to complete an 8.2 transfer. Maybe it would be useful if ARIN staff could detail what the operational practice is in the case of an 8.2 transfer request of dramatically underutilized space?<div>
<br></div><div>I agree with you (and the intent of this proposal is) that it'd be best for ARIN to complete the 8.2 transfer, and then (as this policy states) work with the resource holder(s) to return or transfer whatever portions of the transferred space are unused. Obviously the degree to which the acquirer could do that would be determined by just how fragmented the space is. If it's so fragmented that it's not worth renumbering out of or 8.3 transferring any of the space, then I think the proper thing to do is to instruct the acquiring company that any future growth needs to use the unused fragments, and that they will not qualify to receive any new space until they've done so.</div>
<div><br><div class="gmail_extra">-Scott<br>
<br><div class="gmail_quote">On Wed, Jul 23, 2014 at 4:03 PM, Andrew Dul <span dir="ltr"><<a href="mailto:andrew.dul@quark.net" target="_blank">andrew.dul@quark.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div>
<div>On 7/23/2014 3:00 PM, Scott Leibrand
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Jul 23, 2014 at 2:45 PM,
Andrew Dul <span dir="ltr"><<a href="mailto:andrew.dul@quark.net" target="_blank">andrew.dul@quark.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div><br>
> On 7/23/14, 10:27 , ARIN wrote:<br>
> ...<br>
>> Recommended Draft Policy ARIN-2014-9<br>
>> Resolve Conflict Between RSA and 8.2
Utilization Requirements<br>
>><br>
>> Date: 23 July 2014<br>
>><br>
>> AC's assessment of conformance with the
Principles of Internet Number<br>
>> Resource Policy:<br>
>><br>
>> "This proposal enables fair and impartial
number resource administration<br>
>> by eliminating conflicting language in the
NRPM with the RSA. This<br>
>> proposal is technically sound. The NRPM
should not contain language that<br>
>> conflicts with the RSA. This proposal is
supported by the community.<br>
>> This proposal reflects current practice."<br>
>><br>
>> Problem Statement:<br>
>><br>
>> 8.2 transfer policy has utilization
requirements at the time of the<br>
>> review of the transfer request.<br>
>><br>
>> The RSA section 6 expressly forbids ARIN from
de-registering blocks (in<br>
>> whole or in part) due to under-utilization or
no-justification during<br>
>> transfer requests.<br>
>><br>
>> This is a direct conflict.<br>
>><br>
>> Policy statement:<br>
>><br>
>> Remove the words "aggregate" and "reclaim"
from 8.2, so it reads:<br>
>><br>
>> "In the event that number resources of the
combined organizations are no<br>
>> longer justified under ARIN policy at the
time ARIN becomes aware of the<br>
>> transaction, through a transfer request or
otherwise, ARIN will work<br>
>> with the resource holder(s) to return or
transfer resources as needed to<br>
>> restore compliance via the processes outlined
in current ARIN policy."<br>
><br>
<br>
</div>
</div>
I do not support this draft policy as written.<br>
<br>
This current draft does not do anything substantive to fix
the conflict<br>
in the NRPM which exists because the RSA contractually
obligates ARIN<br>
not to reclaim address space for underutilization. </blockquote>
<div><br>
</div>
<div>You are correct that the RSA contractually obligates
ARIN not to reclaim address space. That is why
ARIN-2014-9 removes that word ("reclaim"). Given that, I'm
not sure why you say that this "doesn't do anything
substantive to fix the conflict".</div>
</div>
</div>
</div>
</blockquote>
<br></div></div>
ARIN today can't reclaim the space nor force an organization it to
aggregate because of the RSA terms, so those two words being in the
NRPM don't do anything. So removing them doesn't do anything
either, in my opinion. The real issue is in the utilization
requirement on 8.2 transfers.<div><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The
current 8.2<br>
policy and this proposed draft change will still result in
orphan blocks<br>
with incorrect stale registry information even when
legitimate network<br>
mergers and acquisitions occur.<br>
</blockquote>
<div><br>
</div>
<div>Why do you say that? Do you feel that when
organizations acquire space via M&A, they will be
afraid of ARIN working with them to voluntarily return or
transfer unneeded resources, and will instead fail to tell
ARIN about the transaction? I understand that fear based
on the current language (which threatens reclamation), but
I'm having trouble understanding how that would remain a
concern once all ARIN is directed to do is work with the
resource holder to do something voluntary.</div>
</div>
</div>
</div>
</blockquote>
<br></div>
Org A purchases Org B (and its network). Org A asks ARIN to update
Org B's records to show that Org A now owns Org B. Org B's address
space is vastly underutilized and Org A+B's combined growth doesn't
meet current policy utilization requirements for Org B's
netblocks. The current 8.2 policy prevents ARIN from updating Org
B's netblocks to show that Org A now is the legitimate rights holder
for Org B's netblocks because it doesn't meet the utilization
requirements in 8.2. Org A estimates it would take $x million
dollars to migrate all the services currently scattered in Org B's
netblocks into other blocks so that some blocks could be transferred
or returned. Org A gives up on the 8.2 transfer request, and thus
we end up with Org B's records being orphaned with incorrect
registration information. Someone from Org A continues to pay the
maintenance or membership fees for Org B (if its not legacy
non-LRSA) and the registry records continue to _not_ show Org A as
the legitimate rights holder for Org B's netblocks.<div><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
The RSA is the controlling document between an
organization and ARIN,<br>
and the NRPM should not have policy which directly
contradicts the<br>
contractual limitations or obligations of the RSA.<br>
</blockquote>
<div><br>
</div>
<div>I do not see how the remaining language ("In the event
that number resources of the combined organizations are no
longer justified under ARIN policy at the time ARIN
becomes aware of the transaction, through a transfer
request or otherwise, ARIN will work with the resource
holder(s) to return or transfer resources as needed to
restore compliance via the processes outlined in current
ARIN policy.") directly (or indirectly) contradicts the
contractual limitations or obligations of the RSA.
Perhaps you could provide more details on why you think
it does?</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div>
If an organization voluntarily wants to return or transfer address
space that is fine. However, if the blocks aren't utilized to
today's utilization policies, an org may choose not to update their
records because that is easier and in their best interest. I
postulate that it is better to let legitimate M&A activities
show the actual rights older of the address blocks, rather than
previous holders even if that allows transfers to occur for
underutilized netblocks. The hypothetical above shows how an
organization even with the best intentions to keep their registry
data up-to-date will make a business decision to just continue like
the transfer never occurred from a registry data perspective.<span><font color="#888888"><br>
<br>
Andrew<br>
<br>
</font></span></div>
</blockquote></div><br></div></div></div>