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.
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.
We see ebay, amazon, craig's list all using whois information.
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.
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 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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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 , [email protected]
<mailto:[email protected]> 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
<[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>>
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 ([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]
<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]
<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.
--
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
([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] <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]
<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.
