<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jul 15, 2017 at 10:24 AM, William Herrin <span dir="ltr"><<a href="mailto:bill@herrin.us" target="_blank">bill@herrin.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Sat, Jul 15, 2017 at 8:52 AM, John Curran <span dir="ltr"><<a href="mailto:jcurran@arin.net" target="_blank">jcurran@arin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word"><div><div>Such a separation doesn’t preclude the community from adopting policy which</div>
<div>references the present or future state of routing (note, for example, the use of</div>
<div>“multihoming” criteria in several portions of the NRPM), but folks are reminded</div>
<div>that in Internet number resource policy we should only be specifying how the </div>
<div>ARIN registry is to be administered, not how things are to be routed, since the </div>
<div>latter is up to each ISP. </div></div></div></blockquote><div><br></div></span><div>Hi John,<br><br></div><div>In the interests of clarifying your remarks:<br><br></div><div>ARIN does not set or even recommend routing policy. Participants in the ARIN policy process routinely consider industry routing practices, IETF recommendations, etc. when suggesting ARIN address management policy and ARIN routinely enacts such policy.<br></div><div><br></div><div>Right?<br></div></div></div></div></blockquote><div><br></div><div>That is true, but I think John is making a stronger point, which I'll make here: It's perfectly fine for ARIN policy to be contingent on (applied differently depending on) how a particular block is (going to be) routed.  So if we think it's the right thing to do, we could require in the NRPM that all blocks in the global routing system be SWIP'ed.  But we *can't* enforce such a requirement by saying, for example, that ISPs can't accept a block until it's SWIP'ed.  We can only issue guidelines on what should be SWIP'ed and make ARIN services (like allocation of additional blocks) contingent on whether such a policy is followed.  If an enforced SWIP-before-routing rule is desired by the ISPs that participate in the global routing system, then they'll have to do so voluntarily by refusing to accept the announcement of non-SWIP'ed blocks.</div><div><br></div><div>-Scott</div></div></div></div>