<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 25, 2013, at 5:33 PM, Jason Schiller <<a href="mailto:jschiller@google.com">jschiller@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">The policy is a little hard to parse...</div><div class="gmail_extra"><br></div><div class="gmail_extra">On Wed, Sep 25, 2013 at 6:55 PM, Owen DeLong <span dir="ltr"><<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</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"></blockquote>| As to moving, yes, corporations often use DNS changes to move the<br>
| service for "<a href="http://www.support.foocorp.com/" target="_blank">www.support.foocorp.com</a>" from one place to another (or<br>| to balance it across many locations), but that's DNS. Policy here is<br>
| about the numbers and corporations rarely move the numbers around<br>| in such a scheme. (Anycast notwithstanding, but I would treat any cast<br>| as used in region so long as at least one site advertising the any cast<br>
| prefix was in region).<br><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">What I can't tell is if this is changing current ARIN practice, and if so, making</div><div class="gmail_extra">it more restrictive or less restrictive.</div></div></blockquote><div><br></div>My understanding is that it would make a slight change to current ARIN practice</div><div>making it slightly less restrictive.</div><div><br><blockquote type="cite"><div dir="ltr">
<div class="gmail_extra">With respect to a global contiguous network that operates, in part, in the </div><div class="gmail_extra">ARIN service region, and advertises reachability for all of the aggregates</div>
<div class="gmail_extra">both in the ARIN service region, and outside the ARIN service region,</div><div class="gmail_extra">count their utilization of equipment and customers of this global network </div><div class="gmail_extra">
regardless of where they are.</div></div></blockquote><div><br></div>Unfortunately, no, this is not entirely current practice. If you can justify everything</div><div>you need based on in-region devices, then ARIN won't complain about your</div><div>out-of-region usage, but if you come back for more, you need to be able to</div><div>justify your additional need strictly using in-region devices. If you tell ARIN</div><div>that you want numbers for your local office and your POP in London, they</div><div>will approve you only for the local office. (It used to be that the POP in London</div><div>was no problem, but not any more).</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">This seems to be current practice, and suggested by Owen that he still </div><div class="gmail_extra">considers it true wrt his anycast statement.</div></div></blockquote><div><br></div>I believe this policy would return us to a better place as described</div><div>above.</div><div><br><blockquote type="cite"><div dir="ltr">
<div class="gmail_extra">"In addition to meeting all other applicable policy requirements, a </div><div>plurality of new resources requested from ARIN must be justified </div><div>by technical infrastructure or customers located within the ARIN </div>
<div>service region, and any located outside the region must be </div><div>interconnected to the ARIN service region. The same technical </div><div>infrastructure or customers cannot be used to justify resources in</div>
<div> more than one RIR."<div class="gmail_extra"><br></div><div class="gmail_extra">This could be read as:</div><div class="gmail_extra"><div>new resources requested from ARIN must be justified by:</div><div>1. technical infrastructure or customers located within the ARIN </div>
<div>service region</div><div><br></div><div>AND</div><div><br></div><div>2. any [technical infrastructure or customers] located outside the </div><div>region [which are] interconnected to the [infrastructure in point 1] in the</div>
<div> ARIN service region. </div></div></div></div></blockquote><div><br></div>Yes, but with the additional caveat that the quantity of resources justified</div><div>by [1] must exceed the amount of resources in any other single RIR region</div><div>justified by [2], and, though the resources in [2] have to be interconnected</div><div>to the ARIN region, they don't necessarily connect to new devices from</div><div>[1] rather than old devices that are already deployed.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div>This would suggest that you get to count the non-ARIN customers that </div><div>are attached to the global network, such as the case now, including the</div><div>case where an Asian company is providing tunnel services to an LA </div>
<div>gateway that is terminating Asian customers.</div></div></div></blockquote><div><br></div>This is only partially the case now sort of under some circumstances.</div><div>The proposal would make it universally the case.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div>This also suggests that you can count utilization of ARIN resources </div><div>outside of the ARIN region in a disconnected network that is wholly </div>
<div>outside the ARIN region so long as this utilization doesn't cross the </div><div>plurality or 20% or 50% threshold.</div></div></div></blockquote><div><br></div>I don't believe that is true. I believe that the requirement is for the</div><div>utilization out of region to be entirely on infrastructure that is part</div><div>of the contiguous interconnection (intra-ORG) with the ARIN region.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div>My understand is today ARIN does not recognize this utilization at all</div>
<div>suggesting this would loosen current practice.</div></div></div></blockquote><div><br></div>Correct.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div><br></div><div>---</div><div><br></div><div>Based on the tone of the conversation, I suspect the community believes </div><div>the reading of the policy is parsed differently:</div>
<div><br></div><div><div>new resources requested from ARIN must be justified only by technical </div><div>infrastructure or customers located within the ARIN service region.</div><div><br></div><div>[In addition,] any [use] located outside the [ARIN] service region must be </div>
<div>interconnected to [a network in] the ARIN service region.</div><div><br></div><div> </div><div>This seems to suggest usage outside the region even in a globally </div><div>connected network that is, in part, within the ARIN service region</div>
<div>does not count towards plurality (or whatever minimum percentage)</div><div>suggesting this policy is more restrictive than current policy.</div><div><br></div><div>Additionally, I have not seen any object to the next clause: <br>
</div></div><div><br></div>"The same technical infrastructure or customers cannot be used to justify<br>resources in more than one RIR."<br></div></div></blockquote><div><br></div>The intent of this statement is to prevent "double dipping". You can't ask</div><div>ARIN for resources for the same pieces of your network in Asia that you</div><div>already received resources from APNIC to number.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div>---</div><div><br></div><div>I agree that double counting should not occur, but there are cases when it</div>
<div>is justified to have multiple addresses on a single piece of equipment or</div><div>to a single customer. Why can't a mix and match approach work.</div><div><br></div><div>For example imagine a server serving https for two domains. It needs two </div>
<div>IP addresses, one for each domain's cert with IP based vhosting. Should </div><div>this operator be precluded from having their previous turned up customers</div><div>continue to have RIPE space, but newly turned up customers on the same</div>
<div>server use ARIN space? What if each service is anycasted on machines in</div><div>the UE and Europe for diversity, and performance? Can the first customer </div><div>on the same hardware use a single IP from RIPE in both locations, and the</div>
<div>second a single IP from ARIN?</div></div></div></blockquote><div><br></div>I think from an RIR perspective, these would not be considered the same</div><div>infrastructure for addressing purposes. Each of the two web servers is</div><div>counted separately, even though they happen to be on the same physical</div><div>piece of hardware.</div><div><br></div><div>If you have better wording to clarify that intent, I'm sure it would be welcome.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div>How about a customer that has a RIPE /24 and has grown beyond their </div><div>current addresses, should they be precluded from getting an additional </div><div>
ARIN /24 and keep their RIPE /24? What if the customer has a single</div><div>network in both the US and Europe and is multi-homed to a single </div><div>provider in the US and Europe?</div></div></div></blockquote><div><br></div>If they have enough additional infrastructure to justify the additional /24, I</div><div>believe this policy would allow that.</div><div><br></div><div>I'm not sure I fully comprehend your meaning in the last sentence.</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div>Or in both cases do they have to number out of RIPE space and into ARIN </div>
<div>space?</div></div></div></blockquote><div><br></div>I think this might make more sense if I understood the previous question.</div><div><br></div><div>Owen</div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div><br></div><div><br></div></div><div class="gmail_extra">___Jason<br><br><div class="gmail_quote">On Wed, Sep 25, 2013 at 6:55 PM, Owen DeLong <span dir="ltr"><<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</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 class="im"><br>
On Sep 25, 2013, at 3:27 PM, John Santos <<a href="mailto:JOHN@egh.com">JOHN@egh.com</a>> wrote:<br>
<br>
> On Wed, 25 Sep 2013, William Herrin wrote:<br>
><br>
>> On Wed, Sep 25, 2013 at 10:59 AM, ARIN <<a href="mailto:info@arin.net">info@arin.net</a>> wrote:<br>
> [...]<br>
><br>
>><br>
>>> , and (2) are operating a<br>
>>> network located within the ARIN service region. In addition to meeting<br>
>>> all other applicable policy requirements, a plurality of new resources<br>
>><br>
>> "Plurality" is a non-starter for me. You really want to do this, pick a<br>
>> percent.<br>
>><br>
>> The reasons have all been stated before, both in the previous<br>
>> discussion, the staff comments and the legal assessment. In context,<br>
>> plurality is a sloppy, hard to pin down concept that makes management<br>
>> and analysis needlessly hard.<br>
><br>
> Huh? "Plurality" is a precisely defined mathematical concept.<br>
><br>
> The part I have a problem with is "a network located within the ARIN<br>
> service region."<br>
<br>
</div>I don't think this is as problematic as you are perceiving.<br>
<div class="im"><br>
> Networks intrinsically span service regions. Nodes can be scattered<br>
> across RIR regions, links between nodes can (and often do) cross regional<br>
> boundaries, and what's worse, nodes can move, both day-to-day (for<br>
> example, an international corporation moves its "<a href="http://www.support.foocorp.com/" target="_blank">www.support.foocorp.com</a>"<br>
> web servers from a data center in Michigan to one in Luxembourg), and<br>
> totally dynamically, as in load-balancing and site failover, as well as<br>
> mobile nodes that can cross RIR boundaries at will. In which region is a<br>
> Liberian-registered cruise ship sailing out of San Diego currently exploring<br>
> the coast of Patagonia? Or an airplane or the ISS?<br>
<br>
</div>In the case of spanning regions and scattered across regions, that is the<br>
reason for the "plurality" provision. It allows a company to keep some<br>
portion of its assets in region and still address its out-of-region assets so<br>
long as none of the other regions contain more of the network using ARIN<br>
region numbers than what is in the ARIN region.<br>
<br>
As to moving, yes, corporations often use DNS changes to move the<br>
service for "<a href="http://www.support.foocorp.com/" target="_blank">www.support.foocorp.com</a>" from one place to another (or<br>
to balance it across many locations), but that's DNS. Policy here is<br>
about the numbers and corporations rarely move the numbers around<br>
in such a scheme. (Anycast notwithstanding, but I would treat any cast<br>
as used in region so long as at least one site advertising the any cast<br>
prefix was in region).<br>
<br>
Mobile nodes that cross RIR boundaries actually tend to get new numbers<br>
when they do so. (At least I haven't roamed across an RIR boundary without<br>
being assigned a new IP address when I did so, and I've been across a lot<br>
of RIR boundaries.<br>
<div class="im"><br>
> There needs to be a degree of fuzziness. If we are going to force a<br>
> regional preponderance of the network (a much vaguer term than<br>
> "plurality"), to be in ARIN's geographical region, then (1) clearly a<br>
<br>
</div>Yes.<br>
<div class="im"><br>
> network with 30% ARIN, 70% RIPE should be getting its resources from RIPE,<br>
<br>
</div>Which would fail the plurality test.<br>
<div class="im"><br>
> but (2) one with 29% ARIN, 28% RIPE, 25% APNIC, and the other 17% spread<br>
> across Africa and Latin America should get their resources from ARIN,<br>
<br>
</div>Which would pass the plurality test.<br>
<div class="im"><br>
> despite having a smaller footprint than the 1st organization. And what of<br>
> (3), which has 28.99% ARIN, 29.01% RIPE right now, but it could change in<br>
> the next 15 minutes? Maybe "within 5% of a plurality in the ARIN region"<br>
> would be a better metric.<br>
<br>
</div>In reality, I think that particular boundary condition is an unlikely corner case.<br>
Where is the other 42% of that network, by the way?<br>
<br>
As I said above, the numbers do not tend to move as quickly as you claim.<br>
Names tend to be quite dynamic. Numbers tend to be fairly stable. If they<br>
were not, BGP would have a much higher (and unsustainable) level of churn.<br>
<div class="im"><br>
> I think right now, an organization can basically deal with the registry it<br>
> finds most convenient, whether for geography, language, culture or<br>
> whatever. The proposal doesn't seem to be about registry shopping (my<br>
<br>
</div>No, actually, most of the other RIRs are much stricter about out-of-region<br>
use of address space than ARIN.<br>
<div class="im"><br>
> local RIR rejected my request or has too many restrictions on my trying to<br>
> commoditize or speculateon the resources, so I'm going take a dip from<br>
> another well), or double-dipping or playing registries off against each<br>
> other. Its goal seems to be accountability of the registrants, so I think<br>
<br>
</div>These are definitely one aspect of the intended policy, but not exclusively,<br>
no.<br>
<div class="im"><br>
> thats what it should try to do directly. It shouldn't matter *where* an<br>
<br>
</div>That is a second aspect of the proposal.<br>
<div class="im"><br>
> organization is based, it should matter whether it is contactable,<br>
> receives and pays its bills, handles abuse complaints and technical<br>
> issues, etc. If these are true, local law enforcement should have no<br>
> problem tracking them down if needed.<br>
<br>
</div>I don't think this is just about law enforcement, though the proposal authors<br>
are primarily representatives of US and Canadian LE organizations. I do<br>
think that the primary intent of the proposal is to address a growing perceived<br>
issue with registry shopping.<br>
<br>
Personally, I'm all for making the process more open to out-of-region usage<br>
as you described, but if you look closely at current ARIN operating practice<br>
and this policy proposal, you will see that the proposal is actually more<br>
liberal about this than current (though not some prior) operating practice.<br>
<span class=""><font color="#888888"><br>
Owen<br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
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">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><font color="#555555" face="'courier new', monospace"><div><span style="font-family: arial; "><font color="#555555" face="'courier new', monospace">_______________________________________________________<br>
</font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br>
</font></div></span></div></font>
</div></div>
</blockquote></div><br></body></html>