> On Jul 25, 2017, at 15:46, Paul McNary <pmcn...@cameron.net> wrote: > > Let me change "geolocation" to "address tracking". > For instance, Netflix blocks a certain region and whois is showing customer > in that region, whereas the customer is actually in a non-blocked region. > If I had my own IPv4 /24 or above I don't have any issue making this entry > correct to ARIN.
I know for a fact that Netflix bases very little (if any) of their geo-fencing on Whois data. > But I have a /25 block from a datacenter that shows I am in California. > Their SWIP policy on IPv4 is /24 to SWIP. > We are trying to minimize these issues as we deploy IPv6 when we have direct > allocation. > I am not debating the "address tracking" issue just brought it up because I > think John made a comment about it. I think if you review the record I stated early on that I didn't believe geolocation was a practical use of Whois. > We see ebay, amazon, craig's list all using whois information. Really? Source needed. In my experience they use other geolocation providers. > Also our /25's have been blocked at the /24 and /18 level. > We had /24's blocked that are reallocated at the parent /18 level. > So unless there is some way to enforce, it just seems to be words on paper. Enforce what? Geolocation is a truly black art and there is no central clearing house or community driven policy body driving its practitioners. > > CHANGE of subject not topic > -------------------------------------- > What I had wished to do on IPv6 deployment is assign an IPv6 /48 to each > Tower(WISP), each POP(ISP) > I would want that switched as will as any individually announced block > smaller than that. > Haven't decided but have a separate /48 to handle DNS, mail servers, etc. ie > Our Infrastructure > Anything less specific that a /48 would just add noise to the world and would > be somewhat proprietary. > I give away some info just advertising my POP's/Towers but I think that would > be for the collective good. :-) > The world doesn't need to know my Access Points or neighborhood routers, etc. I see no reason you can't accomplish this under the proposed policy. I support the current draft as previously stated. Owen > > I think I need to get off my soapbox and take a nap now! > I know I ramble a lot, but getting too old to change much! :-) > Thanks > Take care > Paul > >> On 7/25/2017 5:17 PM, Scott Leibrand wrote: >> If I, as an End User network, want to inform geolocation providers of where >> I'm using each netblock, having them assigned to me in the whois DB with an >> appropriate address is one of the best ways to do that. But if I'm running >> a geolocation service, I can't rely on whois as the sole source of data on >> where an address is used. If I have other info that contradicts the whois >> information, I'd probably just ignore the whois data and go with the facts >> on the ground. >> >> -Scott >> >>> On Tue, Jul 25, 2017 at 3:12 PM, Paul McNary <pmcn...@cameron.net> wrote: >>> Owen >>> Several weeks ago geolocation was one of the arguments for having accurate >>> whois in this thread. >>> This is no longer being argued? >>> Paul >>> >>> >>>> On 7/25/2017 4:26 PM, Owen DeLong wrote: >>>> Huh? >>>> >>>> WHOIS is not a geolocation service and anyone who thinks it is should >>>> reduce their use of recreational pharmaceuticals. >>>> >>>> Owen >>>> >>>>> On Jul 24, 2017, at 12:03 , Paul McNary <pmcn...@cameron.net> wrote: >>>>> >>>>> Then that totally negates the reasoning for geolocation. >>>>> The administrative address could be on the other side of the earth. >>>>> >>>>> Paul >>>>> >>>>> >>>>>> On 7/24/2017 1:31 PM, Owen DeLong wrote: >>>>>>> On Jul 20, 2017, at 14:28 , hostmas...@uneedus.com wrote: >>>>>>> >>>>>>> My transit bus example is another example of SWIP difficulty. Very >>>>>>> hard to provide a street address to SWIP a bus when it is mobile 16 >>>>>>> hours a day. >>>>>> Not at all. A bus would be SWIPd to the bus yard or administrative >>>>>> offices of the bus company. The SWIP data is not required to be the >>>>>> service address, it is required to be an address for administrative >>>>>> and/or technical contact regarding the network and/or legal process >>>>>> service regarding same. >>>>>> >>>>>> [rest trimmed because we are in agreement on that part] >>>>>> >>>>>> Owen >>>>>> >>>>>>>> On Thu, 20 Jul 2017, Chris James wrote: >>>>>>>> @Paul - The API key is to email it. >>>>>>>> >>>>>>>> @Owen - Very difficult when you have dynamic ranges, and vps/container >>>>>>>> platforms spanning tens of thousands of instances across these dynamic >>>>>>>> ranges. >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary <pmcn...@cameron.net> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Owen >>>>>>>>> >>>>>>>>> The reassignment policy page says IPv6 has to be done vi API. >>>>>>>>> Is that something else that is incorrect on the web site? >>>>>>>>> >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>>>>>>>> >>>>>>>>>> How can it be overly difficult to fill out >>>>>>>>>> an email template with your >>>>>>>>>> customers’ >>>>>>>>>> Name, Address, Phone Number? >>>>>>>>>> >>>>>>>>>> Really? >>>>>>>>>> >>>>>>>>>> Owen >>>>>>>>>> >>>>>>>>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>>>>>>>>> <pallie...@pallieter.org> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> ARIN could quantify and require rules >>>>>>>>>>> for when to SWIP, but in the >>>>>>>>>>> end, there are going to be exceptions needed if the rules are to be >>>>>>>>>>> strictly followed. Many will not separately SWIP a separately routed >>>>>>>>>>> sub-block if it is too difficult or pointless to gather and share >>>>>>>>>>> that >>>>>>>>>>> data back upstream to ARIN. >>>>>>>>>>> >>>>>>>>>>> Thus a more fuzzy rule to require a best-effort and to add a >>>>>>>>>>> rule-based reason (preferably both a >>>>>>>>>>> carrot and a stick) for block >>>>>>>>>>> owners to do their best to provide (only) useful data. In order to >>>>>>>>>>> do >>>>>>>>>>> that, one needs to look back at why that data is needed. For a block >>>>>>>>>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>>>>>>>>> and abuse contact requests down to those that are probably more >>>>>>>>>>> likely >>>>>>>>>>> to be able to actually act on the tech/abuse requests (and thus >>>>>>>>>>> reduce >>>>>>>>>>> request-handling workload higher up and overall). But for that to >>>>>>>>>>> work, those tech/abuse contact requests need to be actually handled, >>>>>>>>>>> otherwise, it is better to leave them with the block owner. >>>>>>>>>>> >>>>>>>>>>> In the end, the contact details should >>>>>>>>>>> be as close to the "person" >>>>>>>>>>> that is actually capable to both handle (think: >>>>>>>>>>> volume/languages/etc) >>>>>>>>>>> and act (think: authority) on the tech/abuse requests. >>>>>>>>>>> >>>>>>>>>>> eBrain >>>>>>>>>>> Innovative Internet Ideas >>>>>>>>>>> >>>>>>>>>>> Pallieter Koopmans >>>>>>>>>>> Managing Director >>>>>>>>>>> >>>>>>>>>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>>>>>>>>> Skype: PallieterKoopmans >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> PPML >>>>>>>>>>> You are receiving this message because you are subscribed to >>>>>>>>>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). >>>>>>>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>>>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>>>>>>>> Please contact i...@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@arin.net). >>>>>>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>>>>>>> Please contact i...@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@arin.net). >>>>>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>>>>>> Please contact i...@arin.net if you experience any issues. >>>>>>>> -- >>>>>>>> This e-mail message may contain confidential or legally privileged >>>>>>>> information and is intended only for the use of the intended >>>>>>>> recipient(s). >>>>>>>> Any unauthorized disclosure, dissemination, distribution, copying or >>>>>>>> the >>>>>>>> taking of any action in reliance on the information herein is >>>>>>>> prohibited. >>>>>>>> E-mails are not secure and cannot be guaranteed to be error free as >>>>>>>> they >>>>>>>> can be intercepted, amended, or contain viruses. Anyone who >>>>>>>> communicates >>>>>>>> with us by e-mail is deemed to have accepted these risks. This company >>>>>>>> is >>>>>>>> not responsible for errors or omissions in this message and denies any >>>>>>>> responsibility for any damage arising from the use of e-mail. Any >>>>>>>> opinion >>>>>>>> and other statement contained in this message and any attachment are >>>>>>>> solely >>>>>>>> those of the author and do not necessarily represent those of the >>>>>>>> company. >>>>>>> _______________________________________________ >>>>>>> PPML >>>>>>> You are receiving this message because you are subscribed to >>>>>>> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). >>>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>>>> Please contact i...@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@arin.net). >>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>>> Please contact i...@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@arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact i...@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@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@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@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
