<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Ultimately, I would even go one step further and say that the
requirements need not be the same but can be lower than that of a
registrar in certain cases, namely when the required verification
has already been performed by the registrar. <br>
<br>
So I am lookijng for language that would for example say that the
provider is required to ensure that the underlying data is checked
in a manner consistent with the requirements of the obligations of
the registrar. If the registrar has already checked the underlying
data, there is no need to check it again. <br>
<br>
Best,<br>
<br>
V.<br>
<br>
<div class="moz-cite-prefix">Am 01.03.2014 15:40, schrieb Tim Ruiz:<br>
</div>
<blockquote
cite="mid:EA6EF55F-7303-4AA3-A2D9-D44F5C124DF6@godaddy.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>Yes, that is ultimately my point. Although I do feel even the
requirements of the 2013 RAA are over reaching and ultimately
inaffective in solving any real problems, it is a done deal.
Going beyond that though makes no sense whatsoever.</div>
<div><br>
</div>
<div>Tim</div>
<div><br>
</div>
<div><br>
On Mar 1, 2014, at 4:20 AM, "James M. Bladel" <<a
moz-do-not-send="true" href="mailto:jbladel@godaddy.com">jbladel@godaddy.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div>Hi Alex:</div>
<div><br>
</div>
<div>I believe Tim, Volker and others are saying the
verification requirements for PP services should be the same
as those for Registrars under the 2013 RAA. Nothing more,
and nothing less.</div>
<div><br>
</div>
<div>J.</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt;
text-align:left; color:black; BORDER-BOTTOM: medium none;
BORDER-LEFT: medium none; PADDING-BOTTOM: 0in;
PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df
1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>"<a
moz-do-not-send="true"
href="mailto:Alex_Deacon@mpaa.org">Alex_Deacon@mpaa.org</a>"
<<a moz-do-not-send="true"
href="mailto:Alex_Deacon@mpaa.org">Alex_Deacon@mpaa.org</a>><br>
<span style="font-weight:bold">Date: </span>Friday,
February 28, 2014 at 22:57 <br>
<span style="font-weight:bold">To: </span>Tim Ruiz <<a
moz-do-not-send="true" href="mailto:tim@godaddy.com">tim@godaddy.com</a>><br>
<span style="font-weight:bold">Cc: </span>"<a
moz-do-not-send="true"
href="mailto:gnso-ppsai-pdp-wg@icann.org">gnso-ppsai-pdp-wg@icann.org</a>"
<<a moz-do-not-send="true"
href="mailto:gnso-ppsai-pdp-wg@icann.org">gnso-ppsai-pdp-wg@icann.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re:
[Gnso-ppsai-pdp-wg] For review - updated templates Cat B,
questions 1 and 2<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space;">
<div><br>
</div>
Tim and all,
<div>
<div><br>
</div>
<div>It is not clear to me what you (or Volker or
Stephanie) are suggesting as an alternative. As a
newbie to the ICANN world I’ve not had the pleasure
of being involved in privacy/proxy related
conversations for the past several years (perhaps I
should be grateful) so I admit I may be missing some
context. </div>
<div><br>
</div>
<div>Are you suggesting privacy/proxy provider need
not do any validation on registrant data? I don’t
believe you are, but its far from clear and I don’t
want to make assumptions. </div>
<div><br>
</div>
<div>IMO the goal here is to ensure registrant data is
accurate in the case contact and communication is to
be made with the owner of the domain. And
ultimately that we get a response from the owner of
the domain. We as a working group are not trying to
create a solution that somehow vets or makes a value
(or liability) judgement of what they
do/sell/say/etc on their website. As Stephanie
mentioned we have regimes to deal with this case. </div>
<div><br>
</div>
<div>As an aside, I believe its important to also
think beyond managing the misuse scenario (which
seems to be the current/only focus), and look
further into the future where we have a DNS system,
grounded in DNSSEC, that enables additional trust
services such as DANE. DANE relies on a trusted
identity provided and validated DNSSEC. I’m not
sure how this system can be ultimately successful
(assuming one believes this is a goal) without some
assurance that the WHOIS data is accurate in the
direct WHOIS case or can be found/proven to be
accurate in the privacy/proxy case. </div>
<div><br>
</div>
<div>Thanks for the great debate - I continue to learn
every day. </div>
<div><br>
</div>
<div>Alex</div>
<div><br>
</div>
<div><br>
<div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); font-family:
Helvetica; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: 2;
text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; word-wrap:
break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space; ">
<div style="color: rgb(0, 0, 0); font-family:
Helvetica; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: 2;
text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; word-wrap:
break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space; ">
<b>Alex Deacon<br>
</b>Senior VP, Internet Technology<br>
Motion Picture Association of America<br>
<font color="#0433ff"><a
moz-do-not-send="true"
href="mailto:Alex_Deacon@mpaa.org">Alex_Deacon@mpaa.org</a></font>
<div>+1.415.802.9776 (mobile)<br>
<br>
</div>
</div>
</div>
</div>
<br>
<div>
<div>On Feb 28, 2014, at 7:39 PM, Tim Ruiz <<a
moz-do-not-send="true"
href="mailto:tim@godaddy.com">tim@godaddy.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="auto">
<div>So to make your invsetigation of 150
cases easier (which I question in any event)
millions of users are needlessly hassled.
Makes perfect sense in today's world I
guess.</div>
<div><br>
</div>
<div>Tim</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>On Feb 28, 2014, at 5:32 PM, "John
Horton" <<a moz-do-not-send="true"
href="mailto:john.horton@legitscript.com">john.horton@legitscript.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;color:#073763">
Hi all,</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;color:#073763">
<br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;color:#073763">
Verification and re-verification of
registration data would be enormously
useful and important in identifying,
mapping and deterring malfeasance.
Just to share our background to put
our comments in context, we've
assisted in over 150 drug or
supplement investigations by
conducting cybercrime research, and
each project typically involved
research into dozens, hundreds or even
thousands of Whois records plus
corresponding IP/NS/MX etc.
information. There are numerous
instances in which either 1) the
accurate Whois data (including,
accurate data behind a Whois
privacy/proxy service) "broke open"
the case, or 2) submitting a WDRPS
complaint in instances where we could
show that the Whois data was
inaccurate resulted in modified Whois
information that then "broke open" the
case, either by virtue of the modified
Whois information itself, or from
derivative information (e.g.,
additional reverse queries on Whois,
name server, IP address or other
records). Keep in mind too that
sometimes showing that the Whois
record is falsified results in the
suspension of the domain name, which
also has the effect of stopping the
harmful use of that particular domain
name. Verification would result in
some instances of inaccurate
registration data becoming accurate,
or alternatively, of discontinuing
registration services.<br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;color:#073763">
<br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;color:#073763">
In the interests of brevity, I hope
that summary is enough explanation,
but if anyone still doesn't understand
how (or agree that) verified
registration data -- or by extension,
verification and some sort of periodic
re-verification -- is useful, I'm
happy to provide a couple of real life
examples of investigations we've
worked on where either the a) accuracy
of the Whois record or b) response to
the inaccuracy finding was extremely
useful, although I'll modify the
domain names. Again, I'm happy to
provide real-life examples, with
redacted information. It's not just
occasionally or mildly useful. It's
enormously important. </div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;color:#073763">
<br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;color:#073763">
One additional point: keep in mind
that when researching criminal
networks, there are typically multiple
(hundreds or even thousands) of domain
names at play, and even if -- as Tim
pointed out -- the verified email and
phone number have nothing to do with
the person's real identity, good
cybercrime research across the
thousands of Whois records can often
result in derivative information
pointing to the real identity of the
criminal entities. </div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;color:#073763">
<br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;color:#073763">
As to the point that the domain name
isn't harmful but the content may be,
I suspect that there are minds that
won't be changed in this group on both
sides of that argument. :) But, I'd
point out that that train has left the
station, so to speak: Section 3.18 of
the 2013 RAA clearly contemplates
harmful use of a domain name. </div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;color:#073763">
<br>
</div>
<div class="gmail_default"
style="font-family:arial,helvetica,sans-serif;color:#073763">
Thanks, </div>
<div class="gmail_extra"><br clear="all">
<div>
<div dir="ltr"><font color="#073763"
face="arial,helvetica,sans-serif">John Horton<br>
President, LegitScript</font>
<div> <img moz-do-not-send="true"
src="https://static.legitscript.com/assets/logo-smaller-cdb8a6f307ce2c6172e72257dc6dfc34.png"
width="96" height="21"><br>
<div>
<div>
<div style="margin: 0px;
font-style: normal;
font-variant: normal;
font-weight: normal;
font-size: 12px;
line-height: normal;
font-family: Helvetica;">
<br>
</div>
<div style="margin: 0px;
font-style: normal;
font-variant: normal;
font-size: 12px;
line-height: normal;
font-family: Helvetica;">
<b><font color="#444444">Follow</font><font
color="#0b5394"> </font><font>Legit</font><font
color="#0b5394">Script</font></b>:
<a moz-do-not-send="true"
href="http://www.linkedin.com/company/legitscript-com"
style="font-weight:normal"
target="_blank">
<font color="#cc0000">LinkedIn</font></a>
| <a
moz-do-not-send="true"
href="https://www.facebook.com/LegitScript"
style="font-weight:normal" target="_blank"><font color="#6aa84f">Facebook</font></a>
| <a
moz-do-not-send="true"
href="https://twitter.com/legitscript"
style="font-weight:normal" target="_blank"><font color="#674ea7">Twitter</font></a>
| <a
moz-do-not-send="true"
href="https://www.youtube.com/user/LegitScript"
style="font-weight:normal" target="_blank"><font color="#bf9000">YouTube</font></a>
| <font color="#ff9900"><u><a
moz-do-not-send="true" href="http://blog.legitscript.com/"
target="_blank">Blog</a></u></font>
|<font color="#ff9900"> <font
style="font-weight:normal"><a moz-do-not-send="true"
href="https://plus.google.com/112436813474708014933/posts"
target="_blank">Google+</a></font></font></div>
</div>
</div>
</div>
</div>
</div>
<br>
<br>
<div class="gmail_quote">On Fri, Feb
28, 2014 at 12:36 PM, Tim Ruiz <span
dir="ltr">
<<a moz-do-not-send="true"
href="mailto:tim@godaddy.com"
target="_blank">tim@godaddy.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="auto">
<div>It doesn't. I can use
perfectly good information,
including a verifiable phone
number and email address, that
has nothing to do with who I
really am. As we have tried to
argue before, unsuccessfully,
is that all verification does
is push the "miscreants" to be
better at obfiscating who they
are (and it just isn't that
hard). As you said, it only
results in making it difficult
for everyone for the acts of a
few.</div>
<span><font color="#888888">
<div><br>
</div>
<div>Tim</div>
</font></span>
<div>
<div>
<div><br>
</div>
<div><br>
On Feb 28, 2014, at 2:07
PM, "Stephanie Perrin"
<<a
moz-do-not-send="true"
href="mailto:stephanie.perrin@mail.utoronto.ca"
target="_blank">stephanie.perrin@mail.utoronto.ca</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>My apologies I
totally mis-read that.
So how does verification
catch that then?<br>
<div>
<div>On 2014-02-28, at
1:52 PM, John Horton
wrote:</div>
<br>
<blockquote
type="cite">
<div dir="ltr">
<div
style="font-family:arial,helvetica,sans-serif;color:#073763">Well,
because absent
an accurate
Whois record, it
can be difficult
to know who to
hold
accountable.</div>
<div
style="font-family:arial,helvetica,sans-serif;color:#073763"><br>
</div>
<div
style="font-family:arial,helvetica,sans-serif;color:#073763">Stephanie,
to clarify: I
was saying that
95% of Whois
data in a
certain
sub-category of
criminal or
miscreant
behavior (spam,
malware,
phishing) is
<u>inaccurate</u> (not
"accurate"). </div>
<div
class="gmail_extra"><br
clear="all">
<div>
<div dir="ltr"><font
color="#073763" face="arial,helvetica,sans-serif">John Horton<br>
President,
LegitScript</font>
<div> <img
moz-do-not-send="true"
src="https://static.legitscript.com/assets/logo-smaller-cdb8a6f307ce2c6172e72257dc6dfc34.png"
width="96"
height="21"><br>
<div>
<div>
<div
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal
normal normal
12px/normal
Helvetica">
<br>
</div>
<div
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-style:normal;font-variant:normal;font-size:12px;line-height:normal;font-family:Helvetica"><b><font
color="#444444">Follow</font><font color="#0b5394"> </font><font>Legit</font><font
color="#0b5394">Script</font></b>:
<a
moz-do-not-send="true"
href="http://www.linkedin.com/company/legitscript-com"
style="font-weight:normal"
target="_blank">
<font
color="#cc0000">LinkedIn</font></a>
| <a
moz-do-not-send="true"
href="https://www.facebook.com/LegitScript" style="font-weight:normal"
target="_blank"><font
color="#6aa84f">Facebook</font></a> | <a moz-do-not-send="true"
href="https://twitter.com/legitscript"
style="font-weight:normal" target="_blank"><font color="#674ea7">Twitter</font></a>
| <a
moz-do-not-send="true"
href="https://www.youtube.com/user/LegitScript"
style="font-weight:normal"
target="_blank"><font color="#bf9000">YouTube</font></a> | <font
color="#ff9900"><u><a
moz-do-not-send="true" href="http://blog.legitscript.com/"
target="_blank">Blog</a></u></font>
|<font
color="#ff9900">
<font
style="font-weight:normal"><a
moz-do-not-send="true"
href="https://plus.google.com/112436813474708014933/posts"
target="_blank">Google+</a></font></font></div>
</div>
</div>
</div>
</div>
</div>
<br>
<br>
<div
class="gmail_quote">On
Fri, Feb 28,
2014 at 9:44
AM, Stephanie
Perrin <span
dir="ltr">
<<a
moz-do-not-send="true"
href="mailto:stephanie.perrin@mail.utoronto.ca" target="_blank">stephanie.perrin@mail.utoronto.ca</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div
style="word-wrap:break-word">I
agree, it is
all about
risk...but
what risk are
we really
talking about?
I dont
understand why
a P/P provider
should be
forced to take
on more risk
than other
registrars.
Further,why
should the
registrar be
accountable
for verified
data, once the
original data
verification
is done. If
John is
correct and in
95% of cases
the data from
the P/P
service
provider was
proven
accurate, then
how does any
amount of data
verification
solve the
problem? The
accountability
for miscreant
behaviour of
all kinds
rests with the
domain name
user. IF the
data is
inaccurate,
ramp up the
penalties if
it can be
shown that the
data was
rendered
inaccurate for
the purposes
of fraudulent
activity.
<div>At the
risk of
sounding
overly
philosophical,
It seems to me
that the
Internet
ecosystem is
somehow being
held to
account for
the actions of
individuals.
It is the
individuals
that should be
held to
account. Not
the domain
name, or the
company that
issued it.
Particularly,
I think that
if products
sold are
tainted, then
there is
plenty of
other consumer
protection law
that
applies...why
are we trying
to solve that
problem? </div>
<div>Cheers
Stephanie
perrin
<div>
<div><br>
<div>
<div>On
2014-02-28, at
12:29 PM,
Carlton
Samuels wrote:</div>
<br>
<blockquote
type="cite">
<div dir="ltr">
<div
style="font-family:comic
sans
ms,sans-serif;font-size:large">..which
seems to me
all about risk
management on
part of the
provider. Its
the results
that matter.</div>
<div
style="font-family:comic
sans
ms,sans-serif;font-size:large"><br>
</div>
<div
style="font-family:comic
sans
ms,sans-serif;font-size:large">So,
for all the
possible
permutations,
in line with
those
enumerated by
Volker, might
it not be more
useful to
refer
'verified
credentials'
as a
requirement on
the provider,
allow them to
accept the
business risk
and leave it
to them to
decide how to
do
it.......and,
inherently,
the risks
acceptable to
them for
provisioning
the service?</div>
<div
style="font-family:comic
sans
ms,sans-serif;font-size:large"><br>
</div>
<div
style="font-family:comic
sans
ms,sans-serif;font-size:large">-Carlton </div>
</div>
<div
class="gmail_extra"><br
clear="all">
<div><br>
==============================<br>
Carlton A
Samuels<br>
Mobile: <a
moz-do-not-send="true"
href="tel:876-818-1799" value="+18768181799" target="_blank">876-818-1799</a><br>
<i><font
color="#33CC00">Strategy,
Planning,
Governance,
Assessment
&
Turnaround</font></i><br>
=============================</div>
<br>
<br>
<div
class="gmail_quote">On
Fri, Feb 28,
2014 at 6:29
AM, Volker
Greimann <span
dir="ltr">
<<a
moz-do-not-send="true"
href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.net</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div
text="#000000"
bgcolor="#FFFFFF">Hi John, <br>
<br>
I am having a
bit of a hard
time
understanding
your point
here.<br>
<br>
You are
describing
three
different
cases here,
two of which
will not
benefit from
verification
in the least
bit and one
might, but
only in some
cases:<br>
<br>
a) The data is
accurate, but
stolen: Here
verification
would not
uncover any
issues with
the data as it
is essentially
correct and
will most
likely be
identified as
accurate.<br>
b) The data is
false: Here,
depending on
the methods
used, the
inaccuracy may
be uncovered
and would lead
to an
automated
request to
provide
updated data
or
deactivation
after a set
time.
Remember, in
order to keep
providing
services in a
sensible
manner, this
needs to be
automated in
some form,
i.e. no
individual
record would
likely see any
manual review.<br>
c) The data is
already
accurate: If
the data is
already
correct, what
purpose does
verification
fulfill? The
data cannot
become more
accurate.
Verification
in this case
seems like an
exercise in
self-gratification.<br>
<br>
That said,
even if there
is a benefit
to be derived
from
verification,
such benefits
are achieved
once
verification
concludes.
Re-verification
of already
verified data
fulfills no
purpose
whatsoever. So
if a set of
data has
already been
verified by
the registrar,
there is no
need for the
p/p provider
to again
verify the
same data.
Only if no
verification
is or can be
performed on
the registrar
level does
verification
by providers
come into
play.<br>
<br>
Volker<br>
<br>
<div>Am
28.02.2014
00:32, schrieb
John Horton:<br>
</div>
<div>
<div>
<blockquote
type="cite">
<div dir="ltr">
<div
style="font-family:arial,helvetica,sans-serif;color:rgb(7,55,99)">
<div
style="color:rgb(34,34,34);font-family:arial"><font
color="#073763" face="arial,helvetica,sans-serif">Thanks, Marika. I also
wanted to
provide a
comment
pertaining to
Question 2 in
the
attachments
(relating to
periodic
checks).</font></div>
<div
style="color:rgb(34,34,34);font-family:arial"><font
color="#073763" face="arial,helvetica,sans-serif"><br>
</font></div>
<div
style="color:rgb(34,34,34);font-family:arial"><span
style="color:
rgb(7, 55,
99);
font-family:
arial,
helvetica,
sans-serif;">In
a few of the
recent
discussions,
there's been
some reference
to criminals
always or
nearly always
being
untruthful in
their Whois
records (even
if
privacy-protected),
leading to the
conclusion
that there is
little purpose
in having a
registrar or
any third
party have to
verify or
re-verify the
information
(especially if
it is
difficult to
prove that the
data is
falsified). I
wanted to
share our
experience and
observations
on that point,
in the hope
that it's
relevant to
future
discussion
regarding
Question 2.</span><br>
</div>
<div
style="color:rgb(34,34,34);font-family:arial"><font
color="#073763" face="arial,helvetica,sans-serif"><br>
</font></div>
<div
style="color:rgb(34,34,34);font-family:arial"><font
color="#073763" face="arial,helvetica,sans-serif">Our consistent
observation
has been that
when it comes
to a
particular
sub-category
of criminal
activity,
spam,
phishing,
malware, and
so forth, it's
probably safe
to say that
that statement
is true -- the
registrant's
Whois
information is
nearly always
inaccurate.
Even in cases,
such as some
where we've
worked with
law
enforcement,
when the Whois
record for a
domain name
involved in
spam, phishing
or malware is
privacy-protected
and is
subsequently
unmasked, the
Whois record
is still not
accurate
behind the
privacy
curtain. There
are probably
exceptions,
but that's
what we've
seen well over
95% of the
time. On
occasion, it's
a real address
and phone
number, just
not one
genuinely
connected to
the
registrant. </font></div>
<div
style="color:rgb(34,34,34);font-family:arial"><font
color="#073763" face="arial,helvetica,sans-serif"><br>
</font></div>
<div
style="color:rgb(34,34,34);font-family:arial"><font
color="#073763" face="arial,helvetica,sans-serif">But there are other
types of
criminal
activity where
the Whois
record is not
so regularly
obfuscated.
For example,
we investigate
a lot of
websites
selling
tainted
dietary
supplements
that end up
containing
some toxin or
adulterant
that harms
people. In
those cases,
we've
overwhelmingly
seen that even
if the Whois
record is
privacy-protected,
the trend is
that the
underlying
Whois record
is accurate.
The same has
been true for
illegal or
counterfeit
medical device
websites that
we've
researched. On
illegal
Internet
pharmacies not
engaged in
spam, it's
probably
50-50. (It
might be a
shell
corporation,
but that's
still valuable
information.)</font></div>
<div
style="color:rgb(34,34,34);font-family:arial"><font
color="#073763" face="arial,helvetica,sans-serif"><br>
</font></div>
<div
style="color:rgb(34,34,34);font-family:arial"><font
color="#073763" face="arial,helvetica,sans-serif">One important point to
consider is
that the Whois
registration
can be
relevant
information
from a banking
perspective
for commercial
entities. That
is, some banks
are going to
look at an
online
merchant's
domain name
registration
record and if
it's either
inaccurate or
protected,
they may
require
disclosure, or
ask about any
discrepancy,
which can be
an incentive
for criminals
selling
products
online who
nevertheless
want to get
paid via
credit card to
have an
accurate
Whois.
Hackers,
malware
providers and
spammers will
find a way
around that,
but they don't
necessarily
constitute
"most"
criminal
activity.</font></div>
<div
style="color:rgb(34,34,34);font-family:arial"><font
color="#073763" face="arial,helvetica,sans-serif"><br>
</font></div>
<div
style="color:rgb(34,34,34);font-family:arial"><font
color="#073763" face="arial,helvetica,sans-serif">The point here is, I
think
verification
can still be a
useful and
necessary tool
in either
scenario, even
if it doesn't
uncover useful
information a
portion of the
time. I
realize that
only pertains
to a portion
of the issues
related to
Question 2,
but I hope
that our
observations
on that are
relevant. </font></div>
<div
style="color:rgb(34,34,34);font-family:arial"><font
color="#073763" face="arial,helvetica,sans-serif"><br>
</font></div>
<div
style="color:rgb(34,34,34);font-family:arial"><font
color="#073763" face="arial,helvetica,sans-serif">Thanks, </font></div>
</div>
<div
class="gmail_extra"><br
clear="all">
<div>
<div dir="ltr"><font
color="#073763" face="arial,helvetica, sans-serif">John Horton<br>
President,
LegitScript</font>
<div> <img
moz-do-not-send="true"
src="https://static.legitscript.com/assets/logo-smaller-cdb8a6f307ce2c6172e72257dc6dfc34.png"
width="96"
height="21"><br>
<div>
<div>
<div
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal
normal normal
12px/normal
Helvetica">
<br>
</div>
<div
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font-style:normal;font-variant:normal;font-size:12px;line-height:normal;font-family:Helvetica"><b><font
color="#444444">Follow</font><font color="#0b5394"> </font><font>Legit</font><font
color="#0b5394">Script</font></b>:
<a
moz-do-not-send="true"
href="http://www.linkedin.com/company/legitscript-com"
style="font-weight:normal"
target="_blank">
<font
color="#cc0000">LinkedIn</font></a>
| <a
moz-do-not-send="true"
href="https://www.facebook.com/LegitScript" style="font-weight:normal"
target="_blank"><font
color="#6aa84f">Facebook</font></a> | <a moz-do-not-send="true"
href="https://twitter.com/legitscript"
style="font-weight:normal" target="_blank"><font color="#674ea7">Twitter</font></a>
| <a
moz-do-not-send="true"
href="https://www.youtube.com/user/LegitScript"
style="font-weight:normal"
target="_blank"><font color="#bf9000">YouTube</font></a> | <font
color="#ff9900"><u><a
moz-do-not-send="true" href="http://blog.legitscript.com/"
target="_blank">Blog</a></u></font>
|<font
color="#ff9900">
<font
style="font-weight:normal"><a
moz-do-not-send="true"
href="https://plus.google.com/112436813474708014933/posts"
target="_blank">Google+</a></font></font></div>
</div>
</div>
</div>
</div>
</div>
<br>
<br>
<div
class="gmail_quote">On
Wed, Feb 26,
2014 at 2:39
AM, Marika
Konings <span
dir="ltr">
<<a
moz-do-not-send="true"
href="mailto:marika.konings@icann.org" target="_blank">marika.konings@icann.org</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0
0 0
.8ex;border-left:1px
#ccc
solid;padding-left:1ex">
<div
style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>Dear All,</div>
<div><br>
</div>
<div>Following
our call
yesterday,
please find
attached the
updated
templates for
Category B –
questions 1
& 2.
Please review
these
templates to
make sure the
WG discussions
have been
accurately
reflected and
feel free to
share any
comments /
edits you may
have with the
mailing list.
We've created
a page on the
wiki where
we'll post the
templates that
have been
finalised for
now (noting
that for some
of these the
WG will need
to come back
to the
template at a
later date),
see <a
moz-do-not-send="true"
href="https://community.icann.org/x/ihLRAg" target="_blank">https://community.icann.org/x/ihLRAg</a>. </div>
<div><br>
</div>
<div>The WG
will continue
its
deliberations
on Category B
– Question 2
next week.
Some of the
questions that
came up during
the
conversation
yesterday and
which you are
encouraged to
share your
views on
(and/or add
additional
questions that
need to be
considered in
this context)
are:</div>
<ul>
<li>What would
be the
arguments for
not using the
same standards
/ requirements
for validation
and
verification
as per the
2013 RAA?
</li>
<li>Should
there be a
requirement
for
re-verification,
and if so,
what instances
would trigger
such
re-verification?
</li>
<li>In case of
affliction
between the
P/P service
and the
registrar, if
the
registration
information
has already
been verified
by the
registrar,
should this
exempt the P/P
provider from
doing so?
</li>
<li>Should the
same
requirements
apply to
privacy and
proxy services
or is there a
reason to
distinguish
between the
two?
</li>
</ul>
<div>Best
regards,</div>
<div><br>
</div>
<div>Marika</div>
</div>
<br>
_______________________________________________<br>
Gnso-ppsai-pdp-wg
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Gnso-ppsai-pdp-wg@icann.org" target="_blank">Gnso-ppsai-pdp-wg@icann.org</a><br>
<a
moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg"
target="_blank">https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Gnso-ppsai-pdp-wg mailing list
<a moz-do-not-send="true" href="mailto:Gnso-ppsai-pdp-wg@icann.org" target="_blank">Gnso-ppsai-pdp-wg@icann.org</a><a moz-do-not-send="true" href="https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg</a></pre>
</blockquote>
<br>
</div>
</div>
<pre cols="72">--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: <a moz-do-not-send="true" href="tel:%2B49%20%280%29%206894%20-%209396%20901" value="+4968949396901" target="_blank">+49 (0) 6894 - 9396 901</a>
Fax.: <a moz-do-not-send="true" href="tel:%2B49%20%280%29%206894%20-%209396%20851" value="+4968949396851" target="_blank">+49 (0) 6894 - 9396 851</a>
Email: <a moz-do-not-send="true" href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.net</a>
Web: <a moz-do-not-send="true" href="http://www.key-systems.net/" target="_blank">www.key-systems.net</a> / <a moz-do-not-send="true" href="http://www.rrpproxy.net/" target="_blank">www.RRPproxy.net</a><a moz-do-not-send="true" href="http://www.domaindiscount24.com/" target="_blank">www.domaindiscount24.com</a> / <a moz-do-not-send="true" href="http://www.brandshelter.com/" target="_blank">www.BrandShelter.com</a>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
<a moz-do-not-send="true" href="http://www.facebook.com/KeySystems" target="_blank">www.facebook.com/KeySystems</a><a moz-do-not-send="true" href="http://www.twitter.com/key_systems" target="_blank">www.twitter.com/key_systems</a>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
<a moz-do-not-send="true" href="http://www.keydrive.lu/" target="_blank">www.keydrive.lu</a>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: <a moz-do-not-send="true" href="tel:%2B49%20%280%29%206894%20-%209396%20901" value="+4968949396901" target="_blank">+49 (0) 6894 - 9396 901</a>
Fax.: <a moz-do-not-send="true" href="tel:%2B49%20%280%29%206894%20-%209396%20851" value="+4968949396851" target="_blank">+49 (0) 6894 - 9396 851</a>
Email: <a moz-do-not-send="true" href="mailto:vgreimann@key-systems.net" target="_blank">vgreimann@key-systems.net</a>
Web: <a moz-do-not-send="true" href="http://www.key-systems.net/" target="_blank">www.key-systems.net</a> / <a moz-do-not-send="true" href="http://www.rrpproxy.net/" target="_blank">www.RRPproxy.net</a><a moz-do-not-send="true" href="http://www.domaindiscount24.com/" target="_blank">www.domaindiscount24.com</a> / <a moz-do-not-send="true" href="http://www.brandshelter.com/" target="_blank">www.BrandShelter.com</a>
Follow us on Twitter or join our fan community on Facebook and stay updated:
<a moz-do-not-send="true" href="http://www.facebook.com/KeySystems" target="_blank">www.facebook.com/KeySystems</a><a moz-do-not-send="true" href="http://www.twitter.com/key_systems" target="_blank">www.twitter.com/key_systems</a>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
<a moz-do-not-send="true" href="http://www.keydrive.lu/" target="_blank">www.keydrive.lu</a>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
</pre>
</div>
<br>
_______________________________________________<br>
Gnso-ppsai-pdp-wg
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Gnso-ppsai-pdp-wg@icann.org" target="_blank">Gnso-ppsai-pdp-wg@icann.org</a><br>
<a
moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg"
target="_blank">https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg</a><br>
</blockquote>
</div>
<br>
</div>
_______________________________________________<br>
Gnso-ppsai-pdp-wg
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Gnso-ppsai-pdp-wg@icann.org" target="_blank">Gnso-ppsai-pdp-wg@icann.org</a><br>
<a
moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg"
target="_blank">https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg</a></blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Gnso-ppsai-pdp-wg
mailing list<br>
<a
moz-do-not-send="true"
href="mailto:Gnso-ppsai-pdp-wg@icann.org" target="_blank">Gnso-ppsai-pdp-wg@icann.org</a><br>
<a
moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg"
target="_blank">https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>Gnso-ppsai-pdp-wg
mailing list</span><br>
<span><a
moz-do-not-send="true"
href="mailto:Gnso-ppsai-pdp-wg@icann.org" target="_blank">Gnso-ppsai-pdp-wg@icann.org</a></span><br>
<span><a
moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg"
target="_blank">https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg</a></span></div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
_______________________________________________<br>
Gnso-ppsai-pdp-wg mailing list<br>
<a moz-do-not-send="true"
href="mailto:Gnso-ppsai-pdp-wg@icann.org">Gnso-ppsai-pdp-wg@icann.org</a><br>
<a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg</a></blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</span></div>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gnso-ppsai-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gnso-ppsai-pdp-wg@icann.org">Gnso-ppsai-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann
- Rechtsabteilung -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: <a class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
<a class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a>
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann
- legal department -
Key-Systems GmbH
Im Oberen Werk 1
66386 St. Ingbert
Tel.: +49 (0) 6894 - 9396 901
Fax.: +49 (0) 6894 - 9396 851
Email: <a class="moz-txt-link-abbreviated" href="mailto:vgreimann@key-systems.net">vgreimann@key-systems.net</a>
Web: <a class="moz-txt-link-abbreviated" href="http://www.key-systems.net">www.key-systems.net</a> / <a class="moz-txt-link-abbreviated" href="http://www.RRPproxy.net">www.RRPproxy.net</a>
<a class="moz-txt-link-abbreviated" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a class="moz-txt-link-abbreviated" href="http://www.BrandShelter.com">www.BrandShelter.com</a>
Follow us on Twitter or join our fan community on Facebook and stay updated:
<a class="moz-txt-link-abbreviated" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/key_systems">www.twitter.com/key_systems</a>
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
<a class="moz-txt-link-abbreviated" href="http://www.keydrive.lu">www.keydrive.lu</a>
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
</pre>
</body>
</html>