<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<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;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 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;}
p.gmail-msolistparagraph, li.gmail-msolistparagraph, div.gmail-msolistparagraph
{mso-style-name:gmail-msolistparagraph;
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.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas",serif;
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]-->
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">Volker,<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">I would agree with you that ‘how to maximize accuracy’ may have to be considered later in our work but I would like to think that we could develop accuracy
requirements sooner in the process.<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"><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"> gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org]
<b>On Behalf Of </b>Volker Greimann<br>
<b>Sent:</b> Monday, May 08, 2017 1:06 PM<br>
<b>To:</b> gnso-rds-pdp-wg@icann.org<br>
<b>Subject:</b> [EXTERNAL] Re: [gnso-rds-pdp-wg] authoritative<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>All things considered, the accuracy of the data to provided to the RDS will probably be one of the last points of our agenda. Only after determining how the new system should look, both from a technical framework perspective as well as from a legal, structural
perspective can we even begin to figure out how this new system should tackle data accuracy. It would be my estimation that if a non-public RDS that protects the privacy of all data subjects subject to having their data entered into it were the result of this
WG, as many of us hope, then that in and of itself would already be very helpful with regard to the issue of data accuracy, just as experience shows that data protected by privacy services has an overall better accuracy that public whois data in general.<o:p></o:p></p>
<p><o:p> </o:p></p>
<p>Best,<o:p></o:p></p>
<p>Volker<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Am 08.05.2017 um 17:58 schrieb Greg Shatan:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif">I agree with the proposition that we can disentangle the issue of "data of record" from the issue of accuracy. I strongly disagree with the idea that accuracy is "</span><span style="font-size:9.5pt;font-family:"Arial",sans-serif">probably
outside the scope of our task."</span><span style="font-family:"Verdana",sans-serif"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif">As a matter of fact, accuracy is one of the core issues that this WG was chartered to deal with. This is obvious from a review of the charter, which includes the following statements (emphasis
added):<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif"> </span><b><span style="font-family:"Arial",sans-serif">As part of its Phase 1 deliberations,
</span></b><span style="font-family:"Arial",sans-serif">the PDP WG should work to reach consensus recommendations</span><span style="font-family:"Verdana",sans-serif"><o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto">by considering, <b><i><span style="font-family:"Arial",sans-serif">at a minimum</span></i></b>, the following complex and inter-related questions:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto"><span style="font-family:Symbol">·
</span><b><span style="font-family:"Arial",sans-serif">Users/Purposes: </span></b>Who should have access to gTLD registration data and why?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto"><span style="font-family:Symbol">·
</span><b><span style="font-family:"Arial",sans-serif">Gated Access: </span></b>What steps should be taken to control data access for each user/purpose?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto"><span style="font-family:Symbol">·
</span><b><span style="font-family:"Arial",sans-serif;color:red">Data Accuracy: </span>
</b><span style="color:red">What steps should be taken to improve data <b>accuracy</b>?</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto"><span style="font-family:Symbol">·
</span><b><span style="font-family:"Arial",sans-serif">Data Elements: </span></b>What data should be collected, stored, and disclosed?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto"><span style="font-family:Symbol">·
</span><b><span style="font-family:"Arial",sans-serif">Privacy: </span></b>What steps are needed to protect data and privacy?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto"><span style="font-family:Symbol">·
</span><b><span style="font-family:"Arial",sans-serif">Coexistence: </span></b>What steps should be taken to enable next-generation RDS coexistence with<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto">and replacement of the legacy WHOIS system?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto"><span style="font-family:Symbol">·
</span><b><span style="font-family:"Arial",sans-serif">Compliance: </span></b>What steps are needed to enforce these policies?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto"><span style="font-family:Symbol">·
</span><b><span style="font-family:"Arial",sans-serif">System Model: </span></b>What system requirements must be satisfied by any next-generation RDS<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto">implementation?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto"><span style="font-family:Symbol">·
</span><b><span style="font-family:"Arial",sans-serif">Cost: </span></b>What costs will be incurred and how must they be covered?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto"><span style="font-family:Symbol">·
</span><b><span style="font-family:"Arial",sans-serif">Benefits: </span></b>What benefits will be achieved and how will they be measured?<o:p></o:p></p>
<div style="border:none;border-bottom:dotted windowtext 3.0pt;padding:0in 0in 1.0pt 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:Symbol">·
</span><b><span style="font-family:"Arial",sans-serif">Risks: </span></b>What risks do stakeholders face and how will they be reconciled?<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto">On 8 November, 2012, the ICANN Board passed a
<span style="color:blue">resolution </span>launching the Expert Working Group on<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto">gTLD Registration Directory Services (EWG) to help redefine the purpose of gTLD registration data<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto">and consider how to safeguard the data, and to propose a model for gTLD registration directory<o:p></o:p></p>
<div style="border:none;border-bottom:dotted windowtext 3.0pt;padding:0in 0in 1.0pt 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">services (RDS) to address
<b><span style="color:red">accuracy</span></b>, privacy, and access issues.<o:p></o:p></p>
</div>
<p class="gmail-msolistparagraph" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:0in;margin-left:13.5pt;margin-bottom:.0001pt">
<span style="font-family:Symbol">·</span><span style="font-size:7.0pt"> </span>
<b><span style="font-family:"Arial",sans-serif">What are the fundamental requirements for gTLD registration data?</span></b><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;text-indent:13.5pt">When addressing this question, the PDP WG should consider, at a minimum, users and<o:p></o:p></p>
<div style="border:none;border-bottom:dotted windowtext 3.0pt;padding:0in 0in 1.0pt 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-indent:13.5pt">
purposes and associated access, <b><span style="color:red">accuracy</span></b>, data element, and privacy requirements.<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif">There are also some nice charts on pages 3-4 of the Charter (pp. 69-70 of the Issue Report), which make the same point with greater detail.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif">Accuracy is absolutely a problem we need to address and resolve. Knowing where data came from but not knowing whether (to a fairly high degree of likelihood) that the data is accurate is not
data management; it's just hoarding, but keeping the receipts.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Verdana",sans-serif">Greg <o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<o:p></o:p></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p><a name="UNIQUE_ID_SafeHtmlFilter_UNIQUE_ID_SafeH"></a><b><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#002E62">Greg Shatan<br>
</span></b><span style="font-size:10.0pt;font-family:"Arial",sans-serif">C: 917-816-6428<br>
S: gsshatan<br>
</span><a href="mailto:gregshatanipc@gmail.com" target="_blank"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#1155CC">gregshatanipc@gmail.com</span></a><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Mon, May 8, 2017 at 5:08 AM, Andrew Sullivan <<a href="mailto:ajs@anvilwalrusden.com" target="_blank">ajs@anvilwalrusden.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Hi,<br>
<br>
On Sun, May 07, 2017 at 01:31:14PM -0400, Sam Lanfranco wrote:<br>
> solutions. The key is that it is sourced in such a way that it is<br>
> recognized as Data of Record.<br>
<br>
I think that we mostly agree, but may be quibbling about "source".<br>
What I think is that the DoR is just what it says it is: the data that<br>
is recorded as having come from the original source of that data.<br>
This tells us nothing about whether the original source lied.<br>
<br>
That any given datum is in fact part of the DoR could be demontrated<br>
in different ways, according to the technology in question.[1]<br>
<br>
> Once there is agreement on what should be the Data of Record (the DoR<br>
> fields) for (say) Thin Data, with (say) unconstrained access, there is<br>
> then the question of which access window(s) [locations (SoR) or<br>
> processes (blockchain)] provide DoR.<br>
<br>
We agree about this, yes.<br>
<br>
> As for "can be sure the data is<br>
> correct", that is the validity issue and separate from the Data of<br>
> Record and Sources of Record issues.<br>
<br>
What _I_ at least meant in any locution like that was not "accurate<br>
data" but "canonically correct". That is, when you get the data out<br>
of the system, how can you be sure that you have the DoR? In whois,<br>
the answer is, "You can't". In RDAP, the answer is, "Did you use<br>
HTTPS and follow the referrals in the answers you got?" In some other<br>
possible future system, the answer might be, "Did you check the<br>
cryptographic signatures over the data elements you received, and do<br>
those signatures validate?" We completely agree that the question of<br>
whether the data in the system is an accurate portrayal of the world<br>
is a different question, and probably outside the scope of our task.<br>
<br>
Best regards,<br>
<br>
A<br>
<br>
[1] Historically, we made the demonstration by source repository: we<br>
asked the registry for data for which the registry had to be the<br>
source, owing to the registry's position in the system. So, whether a<br>
name was registered, the identity of the entity whence came the<br>
registration (the registrar), the name servers if any associated,<br>
certain dates, and the status of the domain came from the registry.<br>
All other data came from the registrar, which was the source for other<br>
such data. This was the "thin whois" model. Unfortunately,<br>
NICNAME/WHOIS predated the registry/registrar model, and the graft<br>
onto whois was not too successful, so people decided to use a "thick<br>
registry" model. In this model, the DoR is nominally moved to the<br>
registry, even though registrars may maintain a private copy of<br>
registrant data that is not necessarily linked to the DoR. Any<br>
database geek will tell you that this is a good way to ensure data<br>
synchronization problems, but it's what we have now.<br>
<br>
RDAP as initially designed allows either of these models to be<br>
followed, and it also allows authentication of the data source through<br>
the use of https. With a little ingenuity, RDAP could be extended to<br>
provide cryptographic signatures over the data elements, thereby<br>
permitting widespread caching without the threat of data corruption<br>
(intentional or otherwise). It's a live question whether the<br>
engineering effort necessary would be worth it, though I confess I'm<br>
pretty sceptical.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
--<br>
Andrew Sullivan<br>
<a href="mailto:ajs@anvilwalrusden.com">ajs@anvilwalrusden.com</a><br>
_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>gnso-rds-pdp-wg mailing list<o:p></o:p></pre>
<pre><a href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><o:p></o:p></pre>
<pre><a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><o:p></o:p></pre>
</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">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">www.key-systems.net</a> / <a href="http://www.RRPproxy.net">www.RRPproxy.net</a><o:p></o:p></pre>
<pre><a href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a href="http://www.BrandShelter.com">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">www.facebook.com/KeySystems</a><o:p></o:p></pre>
<pre><a href="http://www.twitter.com/key_systems">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">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">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">www.key-systems.net</a> / <a href="http://www.RRPproxy.net">www.RRPproxy.net</a><o:p></o:p></pre>
<pre><a href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a href="http://www.BrandShelter.com">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">www.facebook.com/KeySystems</a><o:p></o:p></pre>
<pre><a href="http://www.twitter.com/key_systems">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">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>
</body>
</html>