<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Correct, but we can. Should we then have to treat an other (more
remote) source as more authoritative than our data?</p>
<p>Best,</p>
<p>Volker<br>
</p>
<br>
<div class="moz-cite-prefix">Am 02.05.2017 um 16:16 schrieb Greg
Aaron:<br>
</div>
<blockquote
cite="mid:BN6PR13MB18432F4EA4D84C1EEC44F784D9170@BN6PR13MB1843.namprd13.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{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;}
/* List Definitions */
@list l0
{mso-list-id:1203253106;
mso-list-template-ids:-1269284288;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:?;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:?;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:?;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:?;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:?;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:?;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:?;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:?;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:1373651844;
mso-list-template-ids:-471813812;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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"><a moz-do-not-send="true"
name="_MailEndCompose"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext">Unfortunately
the rest of the word can’t peer into your internal
database.<o:p></o:p></span></a></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="font-size:10.0pt;font-family:"Calibri",sans-serif;color:windowtext"><o:p> </o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"><o:p> </o:p></span></span></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> Tuesday, May 2, 2017 10:11 AM<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> Re: [gnso-rds-pdp-wg] authoritative<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>It really depends.<o:p></o:p></p>
<p>The German trade register is authoritative in the latter
sence since it can be relied upon by third parties, because
there is legislation makes it authoritative in that sense.<o:p></o:p></p>
<p>As a registrar, I do not check the whois for determining the
ownership of a domain we manage, I check our own internal data
(unless the registry allows direct modification by the
registrant).
<o:p></o:p></p>
<p>There certainly is no legislation making the registry or the
RDS output legally authoritative.<o:p></o:p></p>
<p>And as for closeness to the source, nothing beats the
registrar (or his resellers).<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 02.05.2017 um 16:04 schrieb Greg
Aaron:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Dear
Paul:</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Hi.
I suggest the latter. A registry contains data that is
considered an official record. </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">As
I mentioned, accuracy is a related but separate issue.
And bogus contact data is inaccurate no matter where it
sits – at the registry or at the registrar.
</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Other
than contact data, the data in registries is accurate.
Registries are the only place that records,
authoritatively and accurately, what domains exist, what
time each domain was entered into the registry and the
term (and therefore the expiration date), the registrar of
record, etc. They accurately record what nameservers a
registrar designates for a domain, and because the
registry is authoritative for that data those nameservers
are the only ones the domain will resolve to.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">And
registries accurately record what contact data the
registrar placed on the record. That contact data may be
inaccurate (even patently false), but it’s what’s on the
official record, and from a legal perspective that has
consequences. </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
am not sure what you mean when you say “there must be some
verification process as between the registry and
registrars. It is my understanding that this already
exists”. The registrars have some data accuracy
responsibilities as spelled out in the RAA, but how much
accuracy they deliver is a separate conversation. At this
time gTLD registries don’t verify the accuracy
(truthfulness) of contact data that registrars put into
the registry. Although some ccTLD registries (like .UK)
have some checks. </span>
<o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">All
best,</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">--Greg</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<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">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
Paul Keating [<a moz-do-not-send="true"
href="mailto:Paul@law.es">mailto:Paul@law.es</a>]
<br>
<b>Sent:</b> Tuesday, May 2, 2017 6:29 AM<br>
<b>To:</b> Greg Aaron <a moz-do-not-send="true"
href="mailto:gca@icginc.com"><gca@icginc.com></a>;
David Cake
<a moz-do-not-send="true"
href="mailto:dave@davecake.net"><dave@davecake.net></a>;
Sam Lanfranco <a moz-do-not-send="true"
href="mailto:sam@lanfranco.net">
<sam@lanfranco.net></a><br>
<b>Cc:</b> <a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> Re: [gnso-rds-pdp-wg] authoritative</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">Greg,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">I
want to make sure I am not confused.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">By
“Authoritative” are we meaning that </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">the
data is most accurate (closest to the source) </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">OR</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">That
it is the one to be relied upon regardless of how close
it is/was to the originating source.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">If
it is the former, then (a) it will originate at the
registrar and (b) we must accept that it may or may not
remember the truth (e.g. Be actually correct info as
opposed to whatever the registrant provided).</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">If
the registries are to one the authoritative source then
there must be some verification process as between the
registry and registrars. It is my understanding that
this already exists and that we were historically
dealing with thin WHOIS as a result of historical
structure of the original registry (which was at the
time also a registrar). The other registrars did not
want Verisign to have information about their customers
for competitive reasons.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">And,
of course for the purposes of the various privacy rules,
it is the registrar as the collecting agent that must
deal with the consent/permission issues relative to
collection and use.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">My
thoughts anyway.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">Paul
Keating</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:
</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"><</span><a
moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg-bounces@icann.org"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">gnso-rds-pdp-wg-bounces@icann.org</span></a><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">>
on behalf of Greg Aaron <</span><a
moz-do-not-send="true" href="mailto:gca@icginc.com"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">gca@icginc.com</span></a><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">><br>
<b>Date: </b>Monday, May 1, 2017 at 6:42 PM<br>
<b>To: </b>David Cake <</span><a
moz-do-not-send="true" href="mailto:dave@davecake.net"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">dave@davecake.net</span></a><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">>,
Sam Lanfranco <</span><a moz-do-not-send="true"
href="mailto:sam@lanfranco.net"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">sam@lanfranco.net</span></a><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">><br>
<b>Cc: </b>"</span><a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">gnso-rds-pdp-wg@icann.org</span></a><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">"
<</span><a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">gnso-rds-pdp-wg@icann.org</span></a><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">><br>
<b>Subject: </b>Re: [gnso-rds-pdp-wg] authoritative</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #B5C4DF
4.5pt;padding:0in 0in 0in
4.0pt;margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"
id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
think Sam and Scott are saying is that contact
(thick) data in registries should never be relied
upon. And since it can't, the logical conclusion is
that we might as well return to thin registries, in
which contact data is held only at registrars. In
such a paradigm an RDS system could retrieve contact
data for you from the distributed registrars, but
there's no reason to store it in registries.
</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">All
that is the opposite of what the GNSO's Thick WHOIS
PDP recently reasoned.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">That
PDP said that gTLD registries must be thick, in
order to deliver a variety of benefits. That PDP WG
also wrote that: "the only authoritative data source
can be the registry as it holds the ultimate sway
over the data. A registrar updates the data at
customer request and is responsible for its
accuracy, but such changes would only become
authoritative once the registry Whois reflects the
change."</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Below
is the relevant section of The Thick WHOIS PDP final
report. As always, our WG should avail itself of
previous work on relevant issues -- so we don't
reinvent the wheel when we don't have to, and we
don't throw out good policy when we don't have to.
Our WG should examine the Thick WHOIS PDP's
reasoning, and I suggest that a deviation from it
should be compelling.
</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">I
have been using the meaning of "authoritative" that
the PDP did below. David Cake, the below helps
explain why the issue is important. As I said
before, the validation of contact data -- whether it
is truthful and accurate -- is a related but
separate issue.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><a moz-do-not-send="true"
href="https://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">https://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf</span></a><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">“Issue
Description</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Here
is the working definition used by the WG while
analysing this issue: "Authoritative, with respect
to provision of Whois services, shall be interpreted
as to signify the single database within a
hierarchical database structure holding the data
that is assumed to be the final authority regarding
the question of which record shall be considered
accurate and reliable in case of conflicting
records; administered by a single administrative
[agent] and consisting of data provided by the
registrants of record through their registrars." A
proposed shorter version is "the data set to be
relied upon in case of doubt".</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Authoritativeness
in a thin Whois environment</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Since
the registrar alone holds most Whois data, its data
is necessarily authoritative as to those data
elements (e.g., name of registrant). For that data
held by both registrar and registry (e.g., name of
registrar), it appears that registry data is
generally treated as authoritative, but the WG is
not aware of any official ICANN policy statement on
this. The WG observes that in the case of the
Uniform Dispute Resolution Policy (UDRP), UDRP
Providers treat the registrar Whois information as
authoritative, which may be the result of the UDRP
having been adopted prior to the emergence of thick
gTLD registries.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Authoritativeness
in a thick Whois environment</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Most
comments that addressed this question stated that
registry data is considered authoritative in the
thick environment. Only one stated that the
registrar data was authoritative. Again, the WG is
not aware of any official ICANN policy statement on
this question. The WG notes that the registrar
remains responsible for the accuracy of the data
under either the thick or thin model, as the
relationship with the registrant remains with the
registrar.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Possible
advantages for authoritativeness in a thick Whois
environment</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Several
comments cited efficiency and trust as advantages of
treating the registry Whois data as authoritative.
The WG supports the view that the registry will hold
the entire data set, and is able to change the data
without informing the registrar (due to closed court
orders or similar events). Therefore, the only
authoritative data source can be the registry as it
holds the ultimate sway over the data. A registrar
updates the data at customer request and is
responsible for its accuracy, but such changes would
only become authoritative once the registry Whois
reflects the change.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Possible
downsides for authoritativeness in a thick Whois
environment</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Several
comments noted that registrars remain responsible
for collecting the data and (to an extent governed
by contract with ICANN) for its accuracy. One
contribution felt this was inconsistent with a
conclusion that registry Whois would be
authoritative in the thick environment. The WG did
not agree that this inconsistency was problematic
(primarily on the grounds stated above that the WG
that any data collected by the registrar becomes
authoritative only after it is incorporated in the
registry database).</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Conclusion</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">The
WG finds that a transition from thin to thick Whois
will have no detrimental effect on
authoritativeness. The WG reviewed the question as
to whether it is necessary for this WG to recommend
a policy on this issue. Based on that review, the WG
has concluded that this is not necessary, given that
thick registries have functioned for many years
without requiring a formal position on
authoritativeness, and the lack of evidence that
this created any problem during previous
thin-to-thick transitions such as .org."</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">It
falls to our RDS WG to create additional policy on
this issue. I think that the logical policy is for
registries to be thick, and the only authoritative
data source can be the registry as it holds the
ultimate sway over the data. A registrar updates the
data at customer request and is responsible for its
accuracy, but such changes would only become
authoritative once the registry Whois reflects the
change.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">All
best,</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">--Greg</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<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">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
</span><a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg-bounces@icann.org"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">gnso-rds-pdp-wg-bounces@icann.org</span></a><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> [</span><a
moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg-bounces@icann.org"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">mailto:gnso-rds-pdp-wg-bounces@icann.org</span></a><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">]
<b>On Behalf Of </b>David Cake<br>
<b>Sent:</b> Monday, May 1, 2017 11:55 AM<br>
<b>To:</b> Sam Lanfranco <</span><a
moz-do-not-send="true"
href="mailto:sam@lanfranco.net"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">sam@lanfranco.net</span></a><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">><br>
<b>Cc:</b> </span><a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">gnso-rds-pdp-wg@icann.org</span></a><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"><br>
<b>Subject:</b> Re: [gnso-rds-pdp-wg]
authoritative</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">While I have no objection in the
abstract to authoritative being used on the sense of
‘according to some recognised authority’, I’m not sure
that is relevant to our discussions.<o:p></o:p></p>
<div>
<p class="MsoNormal">I’m not aware of any external
authority.that are discussing here, mostly it we
were talking about validation it was validation
against a process (such as ensuring email was valid)
rather than validation <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">to an external authority. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I still believe that this sense
of authoritative is NOT the same as the sense in
which we origioonally used the rm within the
requirements, and which prompted the current
discussion, which is the data theoretic sense
loosely congruent to the way the term is used within
the DNS - which is to say, the best source of data
*internal* to the system. An authoritative data
source in that sense would be e.g. the registry
direct, rather than a cache or by a proxy. And the
ongoing confusion keeps bringing me back to you
wanting to avoid the term if we can’t keep
definitions straight for 5 minutes. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">David<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On 1 May 2017, at 8:56 pm,
Sam Lanfranco <<a moz-do-not-send="true"
href="mailto:sam@lanfranco.net">sam@lanfranco.net</a>>
wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">From
Paul Keating's posting and in terms of my
comments:<o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0
level1 lfo3">
here the adjective "authoritative" would
not not mean "recognized as true, valid"
<o:p></o:p></li>
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l0
level1 lfo3">
here the adjective "authoritative" would
mean "official, authorized"<o:p></o:p></li>
</ul>
<p class="MsoNormal">The best that can be done
here is to have official, authorized, Data
of Record from a Source of Record.<br>
The struggle for data quality is an ongoing
struggle, here, everywhere, and always.
<br>
<br>
What the Data of Record data set consists
of, and build with a sensitivity to purpose,
seems to me to be the main rds-pdp-wg task
here.<br>
<br>
As to who has access to what and under what
terms, ICANN might set some terms there, but
ultimately ICANN,<br>
as a stakeholder there will play an advisory
role. National and multilateral policies
will rule above ICANN policy.
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Sam
L.
<o:p></o:p></p>
<p class="MsoNormal"><br>
<br>
<br>
<br>
<o:p></o:p></p>
</div>
<p class="MsoNormal">_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
<a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br>
<a moz-do-not-send="true"
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></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">_______________________________________________
gnso-rds-pdp-wg mailing list
</span><a moz-do-not-send="true"
href="mailto:gnso-rds-pdp-wg@icann.org"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">gnso-rds-pdp-wg@icann.org</span></a><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">
</span><a moz-do-not-send="true"
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"><span
style="font-size:10.5pt;font-family:"Calibri",sans-serif">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</span></a><o:p></o:p></p>
</blockquote>
<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 moz-do-not-send="true" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><o:p></o:p></pre>
<pre><a moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" href="http://www.key-systems.net">www.key-systems.net</a> / <a moz-do-not-send="true" href="http://www.RRPproxy.net">www.RRPproxy.net</a><o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a moz-do-not-send="true" 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 moz-do-not-send="true" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a><o:p></o:p></pre>
<pre><a moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" href="http://www.key-systems.net">www.key-systems.net</a> / <a moz-do-not-send="true" href="http://www.RRPproxy.net">www.RRPproxy.net</a><o:p></o:p></pre>
<pre><a moz-do-not-send="true" href="http://www.domaindiscount24.com">www.domaindiscount24.com</a> / <a moz-do-not-send="true" 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 moz-do-not-send="true" href="http://www.facebook.com/KeySystems">www.facebook.com/KeySystems</a><o:p></o:p></pre>
<pre><a moz-do-not-send="true" 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 moz-do-not-send="true" 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>
</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>