<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Which goes back to why registrars need to offer a free "checkbox"
option for their information to be redacted. Done and done.<br>
</p>
<br>
<div class="moz-cite-prefix">On 6/1/2017 4:15 PM, allison nixon
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACLR7wKEKuKOvGKjUrq5zBkzCEunnLJtN+HhFEYfmJH3e8fq0w@mail.gmail.com">
<div dir="ltr">May as well add this part to it as well:
<div><br>
</div>
<div>>>All those nice uses that whois data is currently
put to that have nothing to do with the service that is
provided to the data subject? Say goodbye to them now!</div>
<div><br>
</div>
<div>This gloating tone is not only unhelpful, but it's likely
not even legally required. Relating to the subject of social
media, there is no way that Facebook public profiles will be
considered less sensitive than WHOIS data. The FindFace app
can already demonstrate that a picture of a face can be used
to identify an individual even if their name is not known. And
I don't forsee Facebook shutting down over this. And if the
laws do require a complete shutdown of all social media, then
the laws are going to change.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Jun 1, 2017 at 5:06 PM, Gomes,
Chuck via gnso-rds-pdp-wg <span dir="ltr"><<a
href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank"
moz-do-not-send="true">gnso-rds-pdp-wg@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 bgcolor="white" link="blue" vlink="purple" lang="EN-US">
<div class="m_7791157209609218819WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">I
apologize for using Volker’s message as an example
but I think it might serve as a useful lesson for
everyone. The clause I highlighted in yellow below
is derogatory and adds no value to the points made.
I ask Volker and everyone to avoid derogatory
remarks and stick to the points that will
constructively contribute to the discussion.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">Chuck</span></p>
<p class="MsoNormal"><a
name="m_7791157209609218819__MailEndCompose"
moz-do-not-send="true"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"> </span></a></p>
<span></span>
<div>
<div style="border:none;border-top:solid #e1e1e1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">
<a
href="mailto:gnso-rds-pdp-wg-bounces@icann.org"
target="_blank" moz-do-not-send="true">gnso-rds-pdp-wg-bounces@icann.<wbr>org</a>
[mailto:<a
href="mailto:gnso-rds-pdp-wg-bounces@icann.org"
target="_blank" moz-do-not-send="true">gnso-rds-pdp-wg-<wbr>bounces@icann.org</a>]
<b>On Behalf Of </b>Volker Greimann<br>
<b>Sent:</b> Thursday, June 01, 2017 12:09 PM<br>
<b>To:</b> <a
href="mailto:gnso-rds-pdp-wg@icann.org"
target="_blank" moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> [EXTERNAL] [gnso-rds-pdp-wg] The
principle of consent</span></p>
</div>
</div>
<div>
<div class="h5">
<p class="MsoNormal"> </p>
<p><span style="background:yellow">As it has been
brought up by Dotzero in a very reckless manner,</span>
I feel it is important to point out what "consent"
actually means in the context of the GDPR:</p>
<p>First, implied consent is no longer sufficient
under the current regulation. The GDPR requires
that the data subject signals agreement to the
specific and defined use of its data by "a
statement or a clear affirmative action".</p>
<p>In other words, an explicit and seperate opt-in
is required, where the action of providing consent
is clearly distinguishable from any other matters
in a written document. This may be ticking a
seperate box on a website or choosing specific
technical settings, but in all cases it must be
based on an explanation of what it is that the
data subject is agreeing to. Silence, pre-ticked
boxes or inactivity is insufficient. Hiding the
consent clauses in the registration agreement is
insufficient.</p>
<p>This consent must be "freely given, specific,
informed and unambiguous."</p>
<p>Fun stuff comes in the next bit:</p>
<p><span class="m_7791157209609218819md">The
controller is required to provide “accurate and
full information on all relevant issues,”
including the nature of the data that will be
processed, the purposes of processing, the
identity of the controller, and<b> the identity
of any other recipients of the data</b>.</span></p>
<p><span class="m_7791157209609218819md">I will
highlight the salient part again: "ANY OTHER
RECIPIENTS OF THE DATA." So no expansion of
those with access at a later data, because that
would immediately invalidate the consent given.</span></p>
<p><span class="m_7791157209609218819md">Finally,
this:</span></p>
<p><span class="m_7791157209609218819md">"Importantly,
a controller may not make a service conditional
upon consent, unless the processing is necessary
for the service."
</span><br>
<span class="m_7791157209609218819md">So no
consent can be construed for any uses beyond the
functioning of the service, the internet and any
other use tied directly to the service. All
those nice uses that whois data is currently put
to that have nothing to do with the service that
is provided to the data subject? Say goodbye to
them now!</span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Further
reading for those so inclined:<br>
<a
href="https://iapp.org/news/a/top-10-operational-impacts-of-the-gdpr-part-3-consent/"
target="_blank" moz-do-not-send="true">https://iapp.org/news/a/top-<wbr>10-operational-impacts-of-the-<wbr>gdpr-part-3-consent/</a><br>
<br>
<span class="m_7791157209609218819md">Also note
that the consent provided by current registrant
does not satisfy the requirements, so what
happens with legacy data with regard to its
import into any RDS system will be a whole new
nightmare down the road.</span></p>
<div>
<p class="MsoNormal">Am 01.06.2017 um 17:41
schrieb Michael Peddemors:</p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">+1 <br>
<br>
On 17-06-01 07:47 AM, Dotzero wrote: <br>
<br>
</p>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">The issue you raise is
addressed simply enough by requiring a privacy
<br>
disclosure be displayed at the time of domain
registration. This <br>
requirement can be incorporated into the ICANN
registry agreements. Note <br>
that this does not resolve the issue for CC
domains. <br>
<br>
Michael Hammer <br>
<br>
On Thu, Jun 1, 2017 at 10:43 AM, Stephanie
Perrin <br>
<<a
href="mailto:stephanie.perrin@mail.utoronto.ca"
target="_blank" moz-do-not-send="true">stephanie.perrin@mail.<wbr>utoronto.ca</a>
<br>
<a
href="mailto:stephanie.perrin@mail.utoronto.ca"
target="_blank" moz-do-not-send="true"><mailto:stephanie.perrin@mail.<wbr>utoronto.ca></a>>
wrote:
<br>
<br>
I certainly agree that if people enter
personal information as part <br>
of their DNS registration or their motor
vehicle licence <br>
registration, it is done with implied
consent... as long as there is <br>
sufficient information to permit them to
understand just how the <br>
data is being used and where it is going.
However, as I tried to <br>
say with respect to registering a domain
name, I really don't think <br>
the average non-expert citizen who might
want to register a domain <br>
name would get enough information to truly
understand how far <br>
his/her information goes, and how
difficult it is to get it removed <br>
once it has appeared in the public
record. We should build this <br>
system so that everyone understands it,
not just the experts. <br>
<br>
cheers Stephanie <br>
<br>
<br>
On 2017-06-01 05:18, jonathan matkowsky
wrote: <br>
<br>
</p>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"> Stephanie, <br>
<br>
I agree with you that we should not
conflate collection <br>
limitation principles with openness
principles. <br>
<br>
I respectfully disagree with most of
what you wrote in the first <br>
paragraph of your post script. <br>
Here we are talking about users
potentially entering personal or <br>
pseudonymous information when they are
not being asked for it (nor <br>
is it required) to begin with, and it is
not required for purposes <br>
of which it's being collected. That is
the <br>
<br>
scope <br>
of what needs to be assessed <br>
if at all and how the scope needs to be
<br>
defined from the beginning <br>
if you were to conduct a PIA <br>
. <br>
<br>
<br>
<br>
<br>
Personal information is not being used
or intended to be used just <br>
because a person decides to enter
personal information into a field. <br>
<br>
The example of how you can combine
databases to re-identify a <br>
person based on the SOA record is the
equivalent of protecting <br>
domain names as personal information
because a person <br>
can register their driver's license <br>
or name and date of birth <br>
as a domain name. <br>
<br>
I would argue no PIA should be required
<br>
as a result <br>
even in accordance even with best
practices. <br>
<br>
A PIA needs to be conducted in a manner
that is commensurate with <br>
the level of privacy risk identified <br>
. <br>
<br>
I respectfully disagree with you that
thin data is personal. We <br>
are talking about identifiers (codes or
strings that represent an <br>
individual or device). Many labels can
be used to point to <br>
individuals. Some are precise and most,
imprecise or vague. <br>
There's no question that an IP address
is a device identifier. <br>
Device IDs, MAC addresses can be a
source for user tracking. But <br>
i <br>
dentifiers can be strong or weak
depending on how precise they <br>
are as well as the context. It cannot be
measured without taking <br>
linkability into consideration. For
that reason, name servers are <br>
not the same as IP addresses or MAC
addresses any more so than the <br>
existence of a domain name is an
identifier. If a person chooses <br>
to use identifiable information when it
is not being asked for or <br>
required for purposes of which the data
is being collected, that <br>
does that mean we need to classify all
the data according to that <br>
unlikely scenario. Those setting up
their own DNS would be <br>
relatively speaking, sophisticated
Internet users that presumably <br>
know the basics of how DNS operates in
any case, so by entering <br>
the information in that way, they are
choosing to customize their <br>
DNS in a personal way similar to a
person that chooses to show <br>
personal information on their license
plate number. <br>
<br>
I know that the motor vehicle registry
is restricted now in most <br>
places so that you would need a subpoena
to get that kind of <br>
personal information. This is also true
of an IP address though <br>
and IP providers. The fact is a person
can put their name and date <br>
of birth on a license plate if they want
to customize it. And then <br>
they get on the road. That does not mean
the license plate numbers <br>
are all personal information. It's
pseudonymous data. It is true <br>
that it is a stronger identifier than an
IP address insofar as if <br>
you subpoena the motor vehicle registry
operator, you will get the <br>
personal information behind that license
plate number. If you <br>
subpoena the ISP, you MIGHT get the
personal information depending <br>
on the nature of the IP address. It's
still true that to drive a <br>
car, you need to show your license plate
number on the vehicle. <br>
<br>
I would argue that thin Whois data is
pseudonymous or personal <br>
data to the same extent that a person
can choose to _customize_ a <br>
license plate if they want to, and put
personal or psuedonymous <br>
data into fields <br>
for which the data being collected does
not ask for or require <br>
them to do so. <br>
<br>
<br>
A <br>
person can register their driver's
license as a domain name. <br>
They can use a personal email in their
SOA record, or personal NS. <br>
Just because it's theoretically possible
for someone to enter <br>
pseudonymous (or even personal) data
into multiple databases when <br>
they are not being asked for it, and
those combination of choices <br>
make it possible to identify them, does
not mean one of the sets <br>
(Thin Whois) should be classified as
personal information subject <br>
to a PIA. <br>
<br>
<br>
<br>
Jonathan Matkowsky, <br>
VP – IP & Brand Security <br>
USA:: <a
href="tel:%28347%29%20467-1193"
value="+13474671193" target="_blank"
moz-do-not-send="true">1.347.467.1193</a>
<a href="tel:%28347%29%20467-1193"
target="_blank" moz-do-not-send="true"><tel:%28347%29%20467-1193></a>
| Office::
<br>
<a href="tel:+972%208-926-2766"
value="+97289262766" target="_blank"
moz-do-not-send="true">+972-(0)8-926-2766</a>
<a href="tel:+972%208-926-2766"
target="_blank" moz-do-not-send="true"><tel:+972%208-926-2766></a>
<br>
Emergency mobile:: <a
href="tel:+972%2054-924-0831"
value="+972549240831" target="_blank"
moz-do-not-send="true">+972-(0)54-924-0831</a>
<a href="tel:+972%2054-924-0831"
target="_blank" moz-do-not-send="true"><tel:+972%2054-924-0831></a>
<br>
Company Reg. No. 514805332 <br>
11/1 Nachal Chever, Modiin Israel <br>
Website <a
href="http://www.riskiq.co.il"
target="_blank" moz-do-not-send="true"><http://www.riskiq.co.il></a>
<br>
RiskIQ Technologies Ltd. (wholly-owned
by RiskIQ, Inc.) <br>
<br>
On Thu, Jun 1, 2017 at 12:02 AM,
Stephanie Perrin <br>
<<a
href="mailto:stephanie.perrin@mail.utoronto.ca"
target="_blank" moz-do-not-send="true">stephanie.perrin@mail.<wbr>utoronto.ca</a>
<br>
<a
href="mailto:stephanie.perrin@mail.utoronto.ca"
target="_blank" moz-do-not-send="true"><mailto:stephanie.perrin@mail.<wbr>utoronto.ca></a>>
wrote:
<br>
<br>
Your summary today was great Andrew.
<br>
<br>
I am not arguing about the
disclosure of thin data. We <br>
already voted on unauthenticated
mandatory disclosure, weeks <br>
ago (or at least it feels like weeks
ago). Lets please move <br>
on. We are debating this yet again,
because people keep <br>
asking, is thin data personal?
[lots of people missed the <br>
last call] The answer is yes
(IMHO). Does that mean it <br>
cannot be disclosed? The answer is
no. Does the <br>
proportionality principle apply?
Yes. Have we already gone <br>
through this? Yes. Can we come
back to it? Yes, but <br>
hopefully only if we have to.....we
will have to when we get <br>
to data elements. <br>
<br>
cheers Stephanie <br>
PS a fundamental problem here is
that people try to categorize <br>
information that in their view
should be disclosed, as not <br>
personal information. This fight
has gone on for years over <br>
IP address, for instance. The
important question is not <br>
actually whether it is personal data
or not, it is "do you <br>
need to disclose it to make things
work?"....and if the answer <br>
is yes then you try to mitigate the
disclosure and try to keep <br>
it minimized to what is absolutely
required. Hence the PIA, <br>
which should employ both data
minimization and the test in the <br>
proportionality principle as
techniques to evaluate data elements. <br>
A good and really simple example is
a phone number. IS it <br>
personal info? (the telcos fought
for years, trying to claim <br>
they owned it and it was not
personal). Obviously it pertains <br>
to you, people feel strongly that it
is personal (culturally <br>
relative of course but...) and yet
if noone ever learns your <br>
number your phone won't ever receive
a call. That does not <br>
mean you have to disclose it
everywhere.....only where <br>
necessary. And it should mean that
it does not have to follow <br>
you everywhere, but that is becoming
increasingly hard to <br>
manage.... <br>
<br>
By the way, informed consent is not
the same as transparency <br>
requirements. Transparency
requirements are exactly <br>
that....you have to be transparent
about what you are doing <br>
with data. Let us not conflate that
with consent. <br>
<br>
I will quit now and stop trying to
answer questions. I would <br>
like to humbly suggest, however,
that we have a real shortage <br>
of basic understanding of how data
protection law works and is <br>
interpreted. If there is a data
protection law expert that <br>
folks might listen to, we should
hire that person to advise <br>
us. It might save a lot of time. <br>
<br>
<br>
On 2017-05-31 16:00, Andrew Sullivan
wrote: <br>
<br>
</p>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"> Hi, <br>
<br>
On Wed, May 31, 2017 at 03:20:59PM
-0400, Stephanie Perrin wrote: <br>
<br>
</p>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"> That does not
mean we need to protect it, it means we
have to examine it in
<br>
terms of DP law. May I repeat
the suggestion that Canatacci made in <br>
Copenhagen in response to a
question.....(I forget the precise
question he
<br>
was asked, sorry). If you want
to figure out whether you have to
protect <br>
something or not, do a privacy
impact assessment. </p>
</blockquote>
<p class="MsoNormal"
style="margin-bottom:12.0pt"> As I
think I've said more than once in this
thread, I think we _have_
<br>
done that assessment and I think
the answers are obvious and I think <br>
therefore that there is nothing
more to say about this principle in <br>
respect of thin data: <br>
<br>
- the data is either necessary
for the operation of the system <br>
itself or else necessary for
distributed operation and <br>
troubleshooting on the
Internet. <br>
<br>
- the data does not expose
identifying information about anyone, <br>
except in rather strained
examples where the identifying <br>
information is already
completely available via other means. <br>
<br>
What more is one supposed to do? <br>
<br>
Best regards, <br>
<br>
A </p>
</blockquote>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><br>
<br>
______________________________<wbr>_________________
<br>
gnso-rds-pdp-wg mailing list <br>
<a
href="mailto:gnso-rds-pdp-wg@icann.org"
target="_blank" moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a>
<a href="mailto:gnso-rds-pdp-wg@icann.org"
target="_blank" moz-do-not-send="true">
<mailto:gnso-rds-pdp-wg@icann.<wbr>org></a>
<br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a>
<br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
target="_blank" moz-do-not-send="true"><https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg></a>
<br>
<br>
</p>
</blockquote>
<p class="MsoNormal"
style="margin-bottom:12.0pt"><br>
<br>
______________________________<wbr>_________________
<br>
gnso-rds-pdp-wg mailing list <br>
<a
href="mailto:gnso-rds-pdp-wg@icann.org"
target="_blank" moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a>
<a href="mailto:gnso-rds-pdp-wg@icann.org"
target="_blank" moz-do-not-send="true">
<mailto:gnso-rds-pdp-wg@icann.<wbr>org></a>
<br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a>
<br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
target="_blank" moz-do-not-send="true"><https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg></a>
<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________
<br>
gnso-rds-pdp-wg mailing list <br>
<a href="mailto:gnso-rds-pdp-wg@icann.org"
target="_blank" moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a>
<br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a>
</p>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
</p>
</blockquote>
<p class="MsoNormal"><br>
<br>
</p>
<pre>-- </pre>
<pre>Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.</pre>
<pre> </pre>
<pre>Mit freundlichen Grüßen,</pre>
<pre> </pre>
<pre>Volker A. Greimann</pre>
<pre>- Rechtsabteilung -</pre>
<pre> </pre>
<pre>Key-Systems GmbH</pre>
<pre>Im Oberen Werk 1</pre>
<pre>66386 St. Ingbert</pre>
<pre>Tel.: <a href="tel:+49%206894%209396901" value="+4968949396901" target="_blank" moz-do-not-send="true">+49 (0) 6894 - 9396 901</a></pre>
<pre>Fax.: <a href="tel:+49%206894%209396851" value="+4968949396851" target="_blank" moz-do-not-send="true">+49 (0) 6894 - 9396 851</a></pre>
<pre>Email: <a href="mailto:vgreimann@key-systems.net" target="_blank" moz-do-not-send="true">vgreimann@key-systems.net</a></pre>
<pre> </pre>
<pre>Web: <a href="http://www.key-systems.net" target="_blank" moz-do-not-send="true">www.key-systems.net</a> / <a href="http://www.RRPproxy.net" target="_blank" moz-do-not-send="true">www.RRPproxy.net</a></pre>
<pre><a href="http://www.domaindiscount24.com" target="_blank" moz-do-not-send="true">www.domaindiscount24.com</a> / <a href="http://www.BrandShelter.com" target="_blank" moz-do-not-send="true">www.BrandShelter.com</a></pre>
<pre> </pre>
<pre>Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:</pre>
<pre><a href="http://www.facebook.com/KeySystems" target="_blank" moz-do-not-send="true">www.facebook.com/KeySystems</a></pre>
<pre><a href="http://www.twitter.com/key_systems" target="_blank" moz-do-not-send="true">www.twitter.com/key_systems</a></pre>
<pre> </pre>
<pre>Geschäftsführer: Alexander Siffrin</pre>
<pre>Handelsregister Nr.: HR B 18835 - Saarbruecken </pre>
<pre>Umsatzsteuer ID.: DE211006534</pre>
<pre> </pre>
<pre>Member of the KEYDRIVE GROUP</pre>
<pre><a href="http://www.keydrive.lu" target="_blank" moz-do-not-send="true">www.keydrive.lu</a> </pre>
<pre> </pre>
<pre>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.</pre>
<pre> </pre>
<pre>------------------------------<wbr>--------------</pre>
<pre> </pre>
<pre>Should you have any further questions, please do not hesitate to contact us.</pre>
<pre> </pre>
<pre>Best regards,</pre>
<pre> </pre>
<pre>Volker A. Greimann</pre>
<pre>- legal department -</pre>
<pre> </pre>
<pre>Key-Systems GmbH</pre>
<pre>Im Oberen Werk 1</pre>
<pre>66386 St. Ingbert</pre>
<pre>Tel.: <a href="tel:+49%206894%209396901" value="+4968949396901" target="_blank" moz-do-not-send="true">+49 (0) 6894 - 9396 901</a></pre>
<pre>Fax.: <a href="tel:+49%206894%209396851" value="+4968949396851" target="_blank" moz-do-not-send="true">+49 (0) 6894 - 9396 851</a></pre>
<pre>Email: <a href="mailto:vgreimann@key-systems.net" target="_blank" moz-do-not-send="true">vgreimann@key-systems.net</a></pre>
<pre> </pre>
<pre>Web: <a href="http://www.key-systems.net" target="_blank" moz-do-not-send="true">www.key-systems.net</a> / <a href="http://www.RRPproxy.net" target="_blank" moz-do-not-send="true">www.RRPproxy.net</a></pre>
<pre><a href="http://www.domaindiscount24.com" target="_blank" moz-do-not-send="true">www.domaindiscount24.com</a> / <a href="http://www.BrandShelter.com" target="_blank" moz-do-not-send="true">www.BrandShelter.com</a></pre>
<pre> </pre>
<pre>Follow us on Twitter or join our fan community on Facebook and stay updated:</pre>
<pre><a href="http://www.facebook.com/KeySystems" target="_blank" moz-do-not-send="true">www.facebook.com/KeySystems</a></pre>
<pre><a href="http://www.twitter.com/key_systems" target="_blank" moz-do-not-send="true">www.twitter.com/key_systems</a></pre>
<pre> </pre>
<pre>CEO: Alexander Siffrin</pre>
<pre>Registration No.: HR B 18835 - Saarbruecken </pre>
<pre>V.A.T. ID.: DE211006534</pre>
<pre> </pre>
<pre>Member of the KEYDRIVE GROUP</pre>
<pre><a href="http://www.keydrive.lu" target="_blank" moz-do-not-send="true">www.keydrive.lu</a> </pre>
<pre> </pre>
<pre>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>
<pre> </pre>
<pre> </pre>
<pre> </pre>
</div>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org"
moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a><br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">_________________________________<br>
Note to self: Pillage BEFORE burning.</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
--
John Bambenek</pre>
</body>
</html>