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 <pmcn...@cameron.net <mailto: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 <mailto: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 <mailto: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
                    <mailto: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
                        <mailto: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
                                <mailto: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
                                    <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@arin.net
                                    <mailto:ARIN-PPML@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 i...@arin.net
                                    <mailto: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
                                <mailto:ARIN-PPML@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 i...@arin.net
                                <mailto: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
                            <mailto:ARIN-PPML@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 i...@arin.net
                            <mailto: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 <mailto:ARIN-PPML@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 i...@arin.net
                    <mailto: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 <mailto:ARIN-PPML@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 i...@arin.net <mailto: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
    <mailto:ARIN-PPML@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 i...@arin.net <mailto: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 <mailto: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 <mailto: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.

Reply via email to