<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Paul,<div class=""><br class=""></div><div class="">Residential customer privacy policy in the NRPM means even if you SWIP them, you’re not</div><div class="">giving up much more data than their Postal code (or possibly a near-by or inclusive</div><div class="">generic Postal code in some cases).</div><div class=""><br class=""></div><div class="">As such, I think your argument here is a bit specious.</div><div class=""><br class=""></div><div class="">Owen</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 15, 2017, at 11:51 , Paul McNary <<a href="mailto:pmcnary@cameron.net" class="">pmcnary@cameron.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
Hello<br class="">
My concern is where the magic boundary will occur. If the swip
boundary includes the<br class="">
recommended /XX for residential customers and small business. I
could see where the<br class="">
whois database could be abused by harvesting our customer
information. Competitors<br class="">
could, would have access and ability to harvest proprietary
information concerning<br class="">
our ISP business. We would have to limit our end user details to the
area which will<br class="">
not be swip'ed to protect our business. That might not be the proper
way to utilize IPv6.<br class="">
Current guidance has been to assign a /56 to even residential
customers and some have<br class="">
recommended a /48 as the minimum assignment. I don't want my
customer information<br class="">
available in such a public accessible database as whois. They could
count my subscribers,<br class="">
harvest their names, addresses and even contact phone numbers. I do
not see this<br class="">
as being good. I would not even like my SMB businesses to have
public information<br class="">
unless they ask for it. I would prefer that the boundary be greater
than /48. With /48<br class="">
not being swip'ed or /56 even that is the minimum end user
allocation.<br class="">
<span itemprop="text" class="">If I understand correctly (many times I do
not) RFC/common agreement that a /32 <br class="">
is the smallest allocation to be announced. I have also have heard
/48. So in my<br class="">
case if it can't be BGP public routable, I don't want to swip it.
What ever my BGP<br class="">
routers can publicly advertise, my BGP gateway, will be assigned
to us. Everything<br class="">
smaller than that, I don't want to publicly advertise.<br class="">
<br class="">
Why would we want the ability to give the competition the tools to
analyze our<br class="">
business with a publicly available tool (ie whois). I also don't
think that if ARIN<br class="">
will not provide an allocation size it shouldn't be swip'ed. So if
ARIN wants to directly<br class="">
provide /56 to end users, then I will rethink my thought process.
Anything smaller than <br class="">
a minimum ARIN allocation, should not have to be swip'ed or under
their control.<br class="">
<br class="">
Am I not understanding this correctly?<br class="">
<br class="">
Thank you<br class="">
Paul McNary<br class="">
McNary Computer Services<br class="">
<a class="moz-txt-link-abbreviated" href="mailto:pmcnary@cameron.net">pmcnary@cameron.net</a><br class="">
</span><br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">On 7/15/2017 12:42 PM, Scott Leibrand
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:CAGkMwz6ichXHwLV8X=2EOh7tUaYgkJ1Dxarwz4CmRLSWebLXRw@mail.gmail.com" class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">On Sat, Jul 15, 2017 at 10:24 AM,
William Herrin <span dir="ltr" class=""><<a href="mailto:bill@herrin.us" target="_blank" moz-do-not-send="true" class="">bill@herrin.us</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote"><span class="">On Sat, Jul
15, 2017 at 8:52 AM, John Curran <span dir="ltr" class=""><<a href="mailto:jcurran@arin.net" target="_blank" moz-do-not-send="true" class="">jcurran@arin.net</a>></span>
wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class="">
<div class="">Such a separation doesn’t preclude the
community from adopting policy which</div>
<div class="">references the present or future state
of routing (note, for example, the use of</div>
<div class="">“multihoming” criteria in several
portions of the NRPM), but folks are
reminded</div>
<div class="">that in Internet number resource policy
we should only be specifying how the </div>
<div class="">ARIN registry is to be administered,
not how things are to be routed, since
the </div>
<div class="">latter is up to each ISP. </div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
</span>
<div class="">Hi John,<br class="">
<br class="">
</div>
<div class="">In the interests of clarifying your remarks:<br class="">
<br class="">
</div>
<div class="">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 class="">
</div>
<div class=""><br class="">
</div>
<div class="">Right?<br class="">
</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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 class=""><br class="">
</div>
<div class="">-Scott</div>
</div>
</div>
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</pre>
</blockquote>
<br class="">
</div>
_______________________________________________<br class="">PPML<br class="">You are receiving this message because you are subscribed to<br class="">the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" class="">ARIN-PPML@arin.net</a>).<br class="">Unsubscribe or manage your mailing list subscription at:<br class=""><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" class="">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br class="">Please contact info@arin.net if you experience any issues.</div></blockquote></div><br class=""></div></body></html>