<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hello Owen<br>
I think we are really almost in total agreement! :-)<br>
I think we use words a little differently, but It think<br>
we want a similar result. "Address Tracking" was not<br>
on my concerns list except for possible CPNI violations<br>
which I see a solution of how to handle this.<br>
</p>
<p>Take care<br>
Paul<br>
</p>
<br>
<div class="moz-cite-prefix">On 7/26/2017 1:13 AM, Owen DeLong
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:C06AD355-7258-4292-B017-63EA8F7A6EB8@delong.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div><br>
</div>
<div><br>
On Jul 25, 2017, at 15:46, Paul McNary <<a
href="mailto:pmcnary@cameron.net" moz-do-not-send="true">pmcnary@cameron.net</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
Let me change "geolocation" to "address tracking".<br>
For instance, Netflix blocks a certain region and whois is
showing customer<br>
in that region, whereas the customer is actually in a
non-blocked region.<br>
If I had my own IPv4 /24 or above I don't have any issue
making this entry correct to ARIN.<br>
</div>
</blockquote>
<div><br>
</div>
I know for a fact that Netflix bases very little (if any) of their
geo-fencing on Whois data.
<div><br>
<blockquote type="cite">
<div> But I have a /25 block from a datacenter that shows I am
in California.<br>
Their SWIP policy on IPv4 is /24 to SWIP.<br>
We are trying to minimize these issues as we deploy IPv6
when we have direct allocation.<br>
I am not debating the "address tracking" issue just brought
it up because I think John made a comment about it.<br>
</div>
</blockquote>
<div><br>
</div>
I think if you review the record I stated early on that I didn't
believe geolocation was a practical use of Whois. </div>
<div><br>
<blockquote type="cite">
<div> We see ebay, amazon, craig's list all using whois
information.<br>
</div>
</blockquote>
<div><br>
</div>
Really? Source needed. </div>
<div><br>
</div>
<div>In my experience they use other geolocation providers. </div>
<div><br>
<blockquote type="cite">
<div> Also our /25's have been blocked at the /24 and /18
level.<br>
We had /24's blocked that are reallocated at the parent /18
level.<br>
So unless there is some way to enforce, it just seems to be
words on paper.<br>
</div>
</blockquote>
<div><br>
</div>
Enforce what? Geolocation is a truly black art and there is no
central clearing house or community driven policy body driving
its practitioners. </div>
<div><br>
<blockquote type="cite">
<div> <br>
CHANGE of subject not topic<br>
--------------------------------------<br>
What I had wished to do on IPv6 deployment is assign an IPv6
/48 to each Tower(WISP), each POP(ISP)<br>
I would want that switched as will as any individually
announced block smaller than that.<br>
Haven't decided but have a separate /48 to handle DNS, mail
servers, etc. ie Our Infrastructure<br>
Anything less specific that a /48 would just add noise to
the world and would be somewhat proprietary.<br>
I give away some info just advertising my POP's/Towers but I
think that would be for the collective good. :-)<br>
The world doesn't need to know my Access Points or
neighborhood routers, etc.<br>
</div>
</blockquote>
<div><br>
</div>
I see no reason you can't accomplish this under the proposed
policy. I support the current draft as previously stated. </div>
<div><br>
</div>
<div><br>
</div>
<div>Owen</div>
<div><br>
</div>
<div>
<blockquote type="cite">
<div> <br>
I think I need to get off my soapbox and take a nap now!<br>
I know I ramble a lot, but getting too old to change much!
:-)<br>
Thanks<br>
Take care<br>
Paul<br>
<br>
<div class="moz-cite-prefix">On 7/25/2017 5:17 PM, Scott
Leibrand wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGkMwz4W8uaax9KcNM1fTbNhA=zSEJYuCGvVL7NxnumiP0-QyA@mail.gmail.com">
<div dir="ltr">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.
<div><br>
</div>
<div>-Scott</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Jul 25, 2017 at 3:12
PM, Paul McNary <span dir="ltr"><<a
href="mailto:pmcnary@cameron.net" target="_blank"
moz-do-not-send="true">pmcnary@cameron.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Owen<br>
Several weeks ago geolocation was one of the
arguments for having accurate whois in this thread.<br>
This is no longer being argued?<span class="HOEnZb"><font
color="#888888"><br>
Paul</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
On 7/25/2017 4:26 PM, Owen DeLong wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex"> Huh?<br>
<br>
WHOIS is not a geolocation service and anyone
who thinks it is should reduce their use of
recreational pharmaceuticals.<br>
<br>
Owen<br>
<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"> On Jul 24,
2017, at 12:03 , Paul McNary <<a
href="mailto:pmcnary@cameron.net"
target="_blank" moz-do-not-send="true">pmcnary@cameron.net</a>>
wrote:<br>
<br>
Then that totally negates the reasoning for
geolocation.<br>
The administrative address could be on the
other side of the earth.<br>
<br>
Paul<br>
<br>
<br>
On 7/24/2017 1:31 PM, Owen DeLong wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"> On Jul 20,
2017, at 14:28 , <a
href="mailto:hostmaster@uneedus.com"
target="_blank" moz-do-not-send="true">hostmaster@uneedus.com</a>
wrote:<br>
<br>
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.<br>
</blockquote>
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.<br>
<br>
[rest trimmed because we are in agreement
on that part]<br>
<br>
Owen<br>
<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"> On Thu, 20
Jul 2017, Chris James wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> @Paul - The
API key is to email it.<br>
<br>
@Owen - Very difficult when you have
dynamic ranges, and vps/container<br>
platforms spanning tens of thousands
of instances across these dynamic<br>
ranges.<br>
<br>
<br>
On Thu, Jul 20, 2017 at 1:51 PM, Paul
McNary <<a
href="mailto:pmcnary@cameron.net"
target="_blank"
moz-do-not-send="true">pmcnary@cameron.net</a>>
wrote:<br>
<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> Owen<br>
<br>
The reassignment policy page says
IPv6 has to be done vi API.<br>
Is that something else that is
incorrect on the web site?<br>
<br>
Paul<br>
<br>
<br>
On 7/20/2017 3:16 PM, Owen DeLong
wrote:<br>
<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> How can
it be overly difficult to fill out
an email template with your<br>
customers’<br>
Name, Address, Phone Number?<br>
<br>
Really?<br>
<br>
Owen<br>
<br>
On Jul 19, 2017, at 23:48 ,
Pallieter Koopmans <<a
href="mailto:Pallieter@pallieter.org"
target="_blank"
moz-do-not-send="true">Pallieter@pallieter.org</a>><br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> wrote:<br>
<br>
Hello,<br>
<br>
ARIN could quantify and require
rules for when to SWIP, but in
the<br>
end, there are going to be
exceptions needed if the rules
are to be<br>
strictly followed. Many will not
separately SWIP a separately
routed<br>
sub-block if it is too difficult
or pointless to gather and share
that<br>
data back upstream to ARIN.<br>
<br>
Thus a more fuzzy rule to
require a best-effort and to add
a<br>
rule-based reason (preferably
both a carrot and a stick) for
block<br>
owners to do their best to
provide (only) useful data. In
order to do<br>
that, one needs to look back at
why that data is needed. For a
block<br>
owner to assign the SWIP on a
sub-block, he basically
delegates tech<br>
and abuse contact requests down
to those that are probably more
likely<br>
to be able to actually act on
the tech/abuse requests (and
thus reduce<br>
request-handling workload higher
up and overall). But for that to<br>
work, those tech/abuse contact
requests need to be actually
handled,<br>
otherwise, it is better to leave
them with the block owner.<br>
<br>
In the end, the contact details
should be as close to the
"person"<br>
that is actually capable to both
handle (think:
volume/languages/etc)<br>
and act (think: authority) on
the tech/abuse requests.<br>
<br>
eBrain<br>
Innovative Internet Ideas<br>
<br>
Pallieter Koopmans<br>
Managing Director<br>
<br>
<a href="tel:%2B31-6-3400-3800"
value="+31634003800"
target="_blank"
moz-do-not-send="true">+31-6-3400-3800</a> (mon-sat
9-22 CET)<br>
Skype: PallieterKoopmans<br>
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message
because you are subscribed to<br>
the ARIN Public Policy Mailing
List (<a
href="mailto:ARIN-PPML@arin.net"
target="_blank"
moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your
mailing list subscription at:<br>
<a
href="http://lists.arin.net/mailman/listinfo/arin-ppml"
rel="noreferrer"
target="_blank"
moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a
href="mailto:info@arin.net"
target="_blank"
moz-do-not-send="true">info@arin.net</a>
if you experience any issues.<br>
<br>
</blockquote>
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message
because you are subscribed to<br>
the ARIN Public Policy Mailing
List (<a
href="mailto:ARIN-PPML@arin.net"
target="_blank"
moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing
list subscription at:<br>
<a
href="http://lists.arin.net/mailman/listinfo/arin-ppml"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a
href="mailto:info@arin.net"
target="_blank"
moz-do-not-send="true">info@arin.net</a>
if you experience any issues.<br>
<br>
</blockquote>
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message
because you are subscribed to<br>
the ARIN Public Policy Mailing List
(<a href="mailto:ARIN-PPML@arin.net"
target="_blank"
moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing
list subscription at:<br>
<a
href="http://lists.arin.net/mailman/listinfo/arin-ppml"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a
href="mailto:info@arin.net"
target="_blank"
moz-do-not-send="true">info@arin.net</a>
if you experience any issues.<br>
</blockquote>
-- <br>
This e-mail message may contain
confidential or legally privileged<br>
information and is intended only for
the use of the intended recipient(s).<br>
Any unauthorized disclosure,
dissemination, distribution, copying
or the<br>
taking of any action in reliance on
the information herein is prohibited.<br>
E-mails are not secure and cannot be
guaranteed to be error free as they<br>
can be intercepted, amended, or
contain viruses. Anyone who
communicates<br>
with us by e-mail is deemed to have
accepted these risks. This company is<br>
not responsible for errors or
omissions in this message and denies
any<br>
responsibility for any damage arising
from the use of e-mail. Any opinion<br>
and other statement contained in this
message and any attachment are solely<br>
those of the author and do not
necessarily represent those of the
company.<br>
</blockquote>
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because
you are subscribed to<br>
the ARIN Public Policy Mailing List (<a
href="mailto:ARIN-PPML@arin.net"
target="_blank" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list
subscription at:<br>
<a
href="http://lists.arin.net/mailman/listinfo/arin-ppml"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a
href="mailto:info@arin.net"
target="_blank" moz-do-not-send="true">info@arin.net</a>
if you experience any issues.<br>
</blockquote>
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you
are subscribed to<br>
the ARIN Public Policy Mailing List (<a
href="mailto:ARIN-PPML@arin.net"
target="_blank" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list
subscription at:<br>
<a
href="http://lists.arin.net/mailman/listinfo/arin-ppml"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a
href="mailto:info@arin.net"
target="_blank" moz-do-not-send="true">info@arin.net</a>
if you experience any issues.<br>
</blockquote>
</blockquote>
<br>
<br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you are
subscribed to<br>
the ARIN Public Policy Mailing List (<a
href="mailto:ARIN-PPML@arin.net"
target="_blank" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list
subscription at:<br>
<a
href="http://lists.arin.net/mailman/listinfo/arin-ppml"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net"
target="_blank" moz-do-not-send="true">info@arin.net</a>
if you experience any issues.</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>PPML</span><br>
<span>You are receiving this message because you are
subscribed to</span><br>
<span>the ARIN Public Policy Mailing List (<a
href="mailto:ARIN-PPML@arin.net" moz-do-not-send="true">ARIN-PPML@arin.net</a>).</span><br>
<span>Unsubscribe or manage your mailing list subscription
at:</span><br>
<span><a
href="http://lists.arin.net/mailman/listinfo/arin-ppml"
moz-do-not-send="true">http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br>
<span>Please contact <a href="mailto:info@arin.net"
moz-do-not-send="true">info@arin.net</a> if you
experience any issues.</span></div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>