[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

[Paul McNary]

Hello
My concern is where the magic boundary will occur. If the swip boundary 
includes the
recommended /XX for residential customers and small business. I could 
see where the
whois database could be abused by harvesting our customer information. 
Competitors
could, would have access and ability to harvest proprietary information 
concerning
our ISP business. We would have to limit our end user details to the 
area which will
not be swip'ed to protect our business. That might not be the proper way 
to utilize IPv6.
Current guidance has been to assign a /56 to even residential customers 
and some have
recommended a /48 as the minimum assignment. I don't want my customer 
information
available in such a public accessible database as whois. They could 
count my subscribers,
harvest their names, addresses and even contact phone numbers. I do not 
see this
as being good. I would not even like my SMB businesses to have public 
information
unless they ask for it. I would prefer that the boundary be greater than 
/48. With /48
not being swip'ed or /56 even that is the minimum end user allocation.
If I understand correctly (many times I do not) RFC/common agreement 
that a /32
is the smallest allocation to be announced. I have also have heard /48. 
So in my
case if it can't be BGP public routable, I don't want to swip it. What 
ever my BGP
routers can publicly advertise, my BGP gateway, will be assigned to us. 
Everything
smaller than that, I don't want to publicly advertise.

Why would we want the ability to give the competition the tools to 
analyze our
business with a publicly available tool (ie whois). I also don't think 
that if ARIN
will not provide an allocation size it shouldn't be swip'ed. So if ARIN 
wants to directly
provide /56 to end users, then I will rethink my thought process. 
Anything smaller than
a minimum ARIN allocation, should not have to be swip'ed or under their 
control.

Am I not understanding this correctly?

Thank you
Paul McNary
McNary Computer Services
pmcnary at cameron.net



On 7/15/2017 12:42 PM, Scott Leibrand wrote:
> On Sat, Jul 15, 2017 at 10:24 AM, William Herrin <bill at herrin.us 
> <mailto:bill at herrin.us>> wrote:
>
>     On Sat, Jul 15, 2017 at 8:52 AM, John Curran <jcurran at arin.net
>     <mailto:jcurran at arin.net>> wrote:
>
>         Such a separation doesn’t preclude the community from adopting
>         policy which
>         references the present or future state of routing (note, for
>         example, the use of
>         “multihoming” criteria in several portions of the NRPM), but
>         folks are reminded
>         that in Internet number resource policy we should only be
>         specifying how the
>         ARIN registry is to be administered, not how things are to be
>         routed, since the
>         latter is up to each ISP.
>
>
>     Hi John,
>
>     In the interests of clarifying your remarks:
>
>     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.
>
>     Right?
>
>
> 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.
>
> -Scott
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170715/8f82629e/attachment.htm>