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

[Owen DeLong]

Paul,

Residential customer privacy policy in the NRPM means even if you SWIP them, you’re not
giving up much more data than their Postal code (or possibly a near-by or inclusive
generic Postal code in some cases).

As such, I think your argument here is a bit specious.

Owen

> On Jul 15, 2017, at 11:51 , Paul McNary <pmcnary at cameron.net> wrote:
> 
> 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 <mailto: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 <mailto:ARIN-PPML at arin.net>).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml <http://lists.arin.net/mailman/listinfo/arin-ppml>
>> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
> 
> _______________________________________________
> 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/20170720/2ce4c8b7/attachment.htm>