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