<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>My apologies. The term reckless was not the one I was looking
for.<br>
</p>
<br>
<div class="moz-cite-prefix">Am 01.06.2017 um 23:06 schrieb Gomes,
Chuck:<br>
</div>
<blockquote type="cite"
cite="mid:6DCFB66DEEF3CF4D98FA55BCC43F152E74BAE0A8@BRN1WNEXMBX02.vcorp.ad.vrsn.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;
        color:black;}
span.md
        {mso-style-name:md;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        color:black;}
span.EmailStyle22
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">Chuck<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"
moz-do-not-send="true"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><o:p> </o:p></span></a></p>
<span style="mso-bookmark:_MailEndCompose"></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 class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg-bounces@icann.org">gnso-rds-pdp-wg-bounces@icann.org</a>
[<a class="moz-txt-link-freetext" href="mailto:gnso-rds-pdp-wg-bounces@icann.org">mailto:gnso-rds-pdp-wg-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 class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> [EXTERNAL] [gnso-rds-pdp-wg] The
principle of consent<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><span style="background:yellow;mso-highlight: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:<o:p></o:p></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".<o:p></o:p></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.<o:p></o:p></p>
<p>This consent must be "freely given, specific, informed and
unambiguous."<o:p></o:p></p>
<p>Fun stuff comes in the next bit:<o:p></o:p></p>
<p><span class="md">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><o:p></o:p></p>
<p><span class="md">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><o:p></o:p></p>
<p><span class="md">Finally, this:</span><o:p></o:p></p>
<p><span class="md">"Importantly, a controller may not make a
service conditional upon consent, unless the processing is
necessary for the service."
</span><br>
<span class="md">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><o:p></o:p></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/"
moz-do-not-send="true">https://iapp.org/news/a/top-10-operational-impacts-of-the-gdpr-part-3-consent/</a><br>
<br>
<span class="md">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><o:p></o:p></p>
<div>
<p class="MsoNormal">Am 01.06.2017 um 17:41 schrieb Michael
Peddemors:<o:p></o:p></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>
<o:p></o:p></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"
moz-do-not-send="true">stephanie.perrin@mail.utoronto.ca</a>
<br>
<a href="mailto:stephanie.perrin@mail.utoronto.ca"
moz-do-not-send="true"><mailto:stephanie.perrin@mail.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>
<o:p></o:p></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:: 1.347.467.1193 <a
href="tel:%28347%29%20467-1193" moz-do-not-send="true"><tel:%28347%29%20467-1193></a>
| Office::
<br>
+972-(0)8-926-2766 <a href="tel:+972%208-926-2766"
moz-do-not-send="true"><tel:+972%208-926-2766></a>
<br>
Emergency mobile:: +972-(0)54-924-0831 <a
href="tel:+972%2054-924-0831" 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"
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"
moz-do-not-send="true">stephanie.perrin@mail.utoronto.ca</a>
<br>
<a href="mailto:stephanie.perrin@mail.utoronto.ca"
moz-do-not-send="true"><mailto:stephanie.perrin@mail.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>
<o:p></o:p></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>
<o:p></o:p></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. <o:p></o:p></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 <o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
_______________________________________________
<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> <a
href="mailto:gnso-rds-pdp-wg@icann.org"
moz-do-not-send="true">
<mailto:gnso-rds-pdp-wg@icann.org></a> <br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
moz-do-not-send="true">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a>
<br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
moz-do-not-send="true"><https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg></a>
<br>
<br>
<o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
_______________________________________________ <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> <a
href="mailto:gnso-rds-pdp-wg@icann.org"
moz-do-not-send="true">
<mailto:gnso-rds-pdp-wg@icann.org></a> <br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
moz-do-not-send="true">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a>
<br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
moz-do-not-send="true"><https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg></a>
<br>
<br>
<br>
<br>
<br>
_______________________________________________ <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"
moz-do-not-send="true">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a>
<o:p></o:p></p>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre>Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Mit freundlichen Grüßen,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Volker A. Greimann<o:p></o:p></pre>
<pre>- Rechtsabteilung -<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Key-Systems GmbH<o:p></o:p></pre>
<pre>Im Oberen Werk 1<o:p></o:p></pre>
<pre>66386 St. Ingbert<o:p></o:p></pre>
<pre>Tel.: +49 (0) 6894 - 9396 901<o:p></o:p></pre>
<pre>Fax.: +49 (0) 6894 - 9396 851<o:p></o:p></pre>
<pre>Email: <a href="mailto:vgreimann@key-systems.net" moz-do-not-send="true">vgreimann@key-systems.net</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Web: <a href="http://www.key-systems.net" moz-do-not-send="true">www.key-systems.net</a> / <a href="http://www.RRPproxy.net" moz-do-not-send="true">www.RRPproxy.net</a><o:p></o:p></pre>
<pre><a href="http://www.domaindiscount24.com" moz-do-not-send="true">www.domaindiscount24.com</a> / <a href="http://www.BrandShelter.com" moz-do-not-send="true">www.BrandShelter.com</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:<o:p></o:p></pre>
<pre><a href="http://www.facebook.com/KeySystems" moz-do-not-send="true">www.facebook.com/KeySystems</a><o:p></o:p></pre>
<pre><a href="http://www.twitter.com/key_systems" moz-do-not-send="true">www.twitter.com/key_systems</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Geschäftsführer: Alexander Siffrin<o:p></o:p></pre>
<pre>Handelsregister Nr.: HR B 18835 - Saarbruecken <o:p></o:p></pre>
<pre>Umsatzsteuer ID.: DE211006534<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Member of the KEYDRIVE GROUP<o:p></o:p></pre>
<pre><a href="http://www.keydrive.lu" moz-do-not-send="true">www.keydrive.lu</a> <o:p></o:p></pre>
<pre><o:p> </o:p></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.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>--------------------------------------------<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Should you have any further questions, please do not hesitate to contact us.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Best regards,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Volker A. Greimann<o:p></o:p></pre>
<pre>- legal department -<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Key-Systems GmbH<o:p></o:p></pre>
<pre>Im Oberen Werk 1<o:p></o:p></pre>
<pre>66386 St. Ingbert<o:p></o:p></pre>
<pre>Tel.: +49 (0) 6894 - 9396 901<o:p></o:p></pre>
<pre>Fax.: +49 (0) 6894 - 9396 851<o:p></o:p></pre>
<pre>Email: <a href="mailto:vgreimann@key-systems.net" moz-do-not-send="true">vgreimann@key-systems.net</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Web: <a href="http://www.key-systems.net" moz-do-not-send="true">www.key-systems.net</a> / <a href="http://www.RRPproxy.net" moz-do-not-send="true">www.RRPproxy.net</a><o:p></o:p></pre>
<pre><a href="http://www.domaindiscount24.com" moz-do-not-send="true">www.domaindiscount24.com</a> / <a href="http://www.BrandShelter.com" moz-do-not-send="true">www.BrandShelter.com</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Follow us on Twitter or join our fan community on Facebook and stay updated:<o:p></o:p></pre>
<pre><a href="http://www.facebook.com/KeySystems" moz-do-not-send="true">www.facebook.com/KeySystems</a><o:p></o:p></pre>
<pre><a href="http://www.twitter.com/key_systems" moz-do-not-send="true">www.twitter.com/key_systems</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>CEO: Alexander Siffrin<o:p></o:p></pre>
<pre>Registration No.: HR B 18835 - Saarbruecken <o:p></o:p></pre>
<pre>V.A.T. ID.: DE211006534<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Member of the KEYDRIVE GROUP<o:p></o:p></pre>
<pre><a href="http://www.keydrive.lu" moz-do-not-send="true">www.keydrive.lu</a> <o:p></o:p></pre>
<pre><o:p> </o:p></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.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
</div>
</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>