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 <[email protected]> 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 > [email protected] <mailto:[email protected]> > > > > On 7/15/2017 12:42 PM, Scott Leibrand wrote: >> On Sat, Jul 15, 2017 at 10:24 AM, William Herrin <[email protected] >> <mailto:[email protected]>> wrote: >> On Sat, Jul 15, 2017 at 8:52 AM, John Curran <[email protected] >> <mailto:[email protected]>> 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 ([email protected] >> <mailto:[email protected]>). >> 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 [email protected] <mailto:[email protected]> if you experience any >> issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
