[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6
Paul McNary
pmcnary at cameron.net
Wed Jul 26 05:11:13 EDT 2017
Hello Owen
I think we are really almost in total agreement! :-)
I think we use words a little differently, but It think
we want a similar result. "Address Tracking" was not
on my concerns list except for possible CPNI violations
which I see a solution of how to handle this.
Take care
Paul
On 7/26/2017 1:13 AM, Owen DeLong wrote:
>
>
> On Jul 25, 2017, at 15:46, Paul McNary <pmcnary at cameron.net
> <mailto:pmcnary at 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 <pmcnary at cameron.net
>>> <mailto:pmcnary at 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
>>> <pmcnary at cameron.net <mailto:pmcnary at 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 ,
>>> hostmaster at uneedus.com
>>> <mailto:hostmaster at 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
>>> <pmcnary at cameron.net
>>> <mailto:pmcnary at 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
>>> <Pallieter at pallieter.org
>>> <mailto:Pallieter at 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
>>> <tel:%2B31-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 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
>>> <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
>>> <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.
>>>
>>> --
>>> 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 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 <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
>>> <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
>> <mailto: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 <mailto: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/20170726/cd12da09/attachment.htm>
More information about the ARIN-PPML
mailing list