<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Indeed this is the current rules, wheich were designed based on
the information available in whois. Such protection mechanisms
make sense and I would recommend that a registrant provide such
information to be better protected. But to mandate it? <br>
</p>
<p>Ultimately, the registrant should be able to weigh his interests
in personal privacy against his interest in better protection. The
registrant can always consent to provide more data than required.<br>
</p>
<p>Best,</p>
<p>Volker<br>
</p>
<br>
<div class="moz-cite-prefix">Am 24.08.2017 um 18:15 schrieb Greg
Aaron:<br>
</div>
<blockquote type="cite"
cite="mid:BN6PR13MB184394AC26C1CCDAB4D9041DD99A0@BN6PR13MB1843.namprd13.prod.outlook.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:"MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@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:"Microsoft JhengHei";
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@Microsoft JhengHei";}
@font-face
{font-family:"\@MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-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;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
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:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
span.EmailStyle20
{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:915090668;
mso-list-template-ids:1202910414;}
@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:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@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:Symbol;}
@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:Symbol;}
@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:Symbol;}
@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:Symbol;}
@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:Symbol;}
@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:Symbol;}
@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:Symbol;}
@list l1
{mso-list-id:1771705084;
mso-list-template-ids:-409305928;}
@list l1: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 l1:level2
{mso-level-number-format:bullet;
mso-level-text:;
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:;
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:;
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:;
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:;
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:;
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:;
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:;
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 name="_MailEndCompose"
moz-do-not-send="true"><span style="color:windowtext">Two WG
calls ago, we had extensive discussion about how legal
processes require multiple methods of contactability. And
require physical addresses, not just electronic service.<o:p></o:p></span></a></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext"><o:p> </o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext">That’s why the UDRP requires:<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext">“Written Notice of the complaint
to all postal-mail and facsimile addresses (A) shown in
the domain name's registration data in Registrar's Whois
database for the registered domain-name holder, the
technical contact, and the administrative contact and (B)
supplied by Registrar to the Provider for the
registration's billing contact; and<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext">(ii) sending the complaint,
including any annexes, in electronic form by e-mail to:<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext">(A) the e-mail addresses for
those technical, administrative, and billing contacts;<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext">(B) postmaster@<the contested
domain name>; and<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext">(C) if the domain name (or "www."
followed by the domain name) resolves to an active web
page (other than a generic page the Provider concludes is
maintained by a registrar or ISP for parking domain-names
registered by multiple domain-name holders), any e- mail
address shown or e-mail links on that web page”<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext"><o:p> </o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext">Such requirements are there to
protect registrants and provide a good process.<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext"><o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext">The “digital nomad” is yet
another corner case.<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext"><o:p> </o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext">All best,<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext">--Greg<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext"><o:p> </o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="color:windowtext"><o:p> </o:p></span></span></p>
<p class="MsoNormal"><span style="mso-bookmark:_MailEndCompose"><span
style="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="color:windowtext">From:</span></b><span
style="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, August 24, 2017 11:41 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] Contractibility,
PBC and required contact methods....<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>I know we have different opinions on this but I feel that one
method of contact should be sufficient. I certainly do not
want to be contacted on my phone by anyone that has an issue
with a domain that I own. While it may be a fast method, it is
also very, very intrusive and we should think twice about
making that number to anyone but those that the registrant
wants to be in possession of his number.
<o:p></o:p></p>
<p>For address details, these have also become much less
relevant. With digital nomads working from anywhere on the
globe, the concept of reaching them through a mailing address
that they would return to maybe once a year is not realistic.
Granted, this is only a small percentile of registrants, but
it exists. Be that as it may, the provision of address data
may also lead to a form of contactibility we should be wary
of: The showing up on one's front lawn. I certainly do not
want anyone I do not care for to turn up at my front door. <o:p></o:p></p>
<p>And with that, I have not even touched upon the data privacy
nightmare that the collection of this details without actual
need for the provision of the service constitutes.<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 24.08.2017 um 17:28 schrieb Greg
Shatan:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">I share and support Alex's concerns
here. I think it helps to unpack the two issues here
and deal with them discretely.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1. The number of contact methods and
whether each is mandatory or optional.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2. The number of contact types.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On the first point, we are clearly
going in a direction that minimizes contactibility.
This runs counter to foundational agreements in the WG,
as Alex points out, and counter to the fundamental
concept of a directory service. At a minimum, the "holy
trinity" of email, phone and physical address need to be
preserved and mandatory. Recognizing that contact
methods evolve, the ability to handle other methods
optionally (various messaging, chat, and voice
platforms) should be included as options, perhaps with
the ability to designate "preferred" methods.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I am slightly (but only slightly)
less concerned about the second point. In WHOIS, many
times the contact types have the identical data. But
that is at least an implicit acknowledgement that the
contact is competent to be designated as that contact
type. With the additional contact types, it's even more
important to emphasize that a designated contact has to
be able to handle contacts of that type. Maybe some
registrants are able to handle all types of
issues/purposes the different contacts address, but that
can't be assumed. Therefore, it is wrong to simply
collapse the different types and treat it as a
presumption that one contact fits all.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Greg<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Aug 24, 2017 at 11:10 AM
Sam Lanfranco <<a href="mailto:sam@lanfranco.net"
moz-do-not-send="true">sam@lanfranco.net</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">I
don't know if this helps, but at least it is a short
read:<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">My
mind keeps going back to the "form follows function"
design idea. The six PBCs are distinct contact
purposes and not necessarily distinct contact
persons. In the existing WHOIS the three contacts
(registrant, admin, tech) were based on the idea
that issues were either technical or admin, or
involved something the registrant should be
contactable for. The PBS types have added Legal,
Abuse, and Proxy/Privacy. Legal and Abuse are an
evolutionary addition based on the development of
the Internet ecosystem and associated intellectual
property and abuse issues. A Proxy/Privacy contact
follows from specific issues that flow from the
growth of proxy/privacy services.
<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><o:p> </o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Without
getting into who has access to what, one can
envision what a user interface might look like, and
that might help identify/clarify issues here. Assume
six purposes (PBCs) and X (1,2,?) mandatory and Y
(1,2,?) optional contact methods. Any contact is for
one of the six purposes (PBCs). The registrant
decides the appropriate options (email, alt-email,
IM, SMS, etc.) from the acceptable list, for each of
the six purposes, to be offered by the RDS and
selected by the query initiator. <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">What
might this entail for the registrant? Consider a
simple forms format. With the six possible query
destinations, the registrant enters a number of
mandated/optional contact options, and may associate
particular contact options with particular query
purposes. For minimal registrant effort the contact
options can be entered once, and drop down menus for
the six purposes can be used to flag certain, some
or all contact options as purpose appropriate. <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><o:p> </o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">What
are the WG decision issues here? Tentatively we have
the six PBCs.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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:l1
level1 lfo3">
We decide on X mandatory contact options. For each
PBC there are X possible choices.
<o:p></o:p></li>
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1
level1 lfo3">
We decide on Y optional options, so for each PBC
there are between one and (X+Y) contact choices.
<o:p></o:p></li>
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1
level1 lfo3">
We decide on what are acceptable contact option
formats.<o:p></o:p></li>
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:0in;mso-list:l1
level1 lfo3">
With 6 contact purposes there should be 6 fields
for contact options.<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">If
the registrant selects only one optional contact for
a purpose, that is the registrant's preferred
contact option. If that fails the query user has the
mandatory contact options to fall back on. <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><o:p> </o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">For
what it is worth....<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><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>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 8/24/2017 8:49 AM, Greg
Aaron wrote:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><a
name="m_7827393201787179921__MailEndCompose"
moz-do-not-send="true">Yes – there appears to
be inconsistency between the goal of decent
contactability and the possible
implementation, which might not deliver on
that promise.</a><o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">All
best,<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">--Greg<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 style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b>
<a
href="mailto:gnso-rds-pdp-wg-bounces@icann.org"
target="_blank" moz-do-not-send="true">gnso-rds-pdp-wg-bounces@icann.org</a>
[<a
href="mailto:gnso-rds-pdp-wg-bounces@icann.org"
target="_blank" moz-do-not-send="true">mailto:gnso-rds-pdp-wg-bounces@icann.org</a>]
<b>On Behalf Of </b>Deacon, Alex<br>
<b>Sent:</b> Wednesday, August 23, 2017 2:56
PM<br>
<b>To:</b> <a
href="mailto:gnso-rds-pdp-wg@icann.org"
target="_blank" moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> [gnso-rds-pdp-wg]
Contractibility, PBC and required contact
methods....<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi
All,<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I’ve
been thinking about the discussion we had on
this week’s call and the preliminary WG
agreements that resulted from those
discussions. E.g.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in"><b>Preliminary
WG Agreement:</b> To improve contactability
with the domain name registrant (or authorized
agent of the registrant), the RDS must be
capable of supporting at least one alternative
contact method as an optional field.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in"><b>Preliminary
WG Agreement:</b> PBC types identified (Admin,
Legal, Technical, Abuse, Proxy/Privacy,
Business) must be supported by the RDS but
optional for registrants to provide<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">While
I understand these are preliminary and
high-level non-concrete concepts I wanted to
point out that the main idea of the these
preliminary WG agreements was to “improve
contractibility”. My concern is that these
agreements do exactly the opposite. <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">In
today’s WHOIS we have 3 mandatory contact types
(a.k.a. PBC): registrant, admin, tech. Each of
those three types mandate at 3 contact methods
(email, phone and physical mail) and allow for
one optional contact method (Fax). i.e.
3*3=9 potential methods to initiate contact with
the registrant. (And before you respond I do
understand that often these contact types
contain the same contact info.) Even when
all 3 contact types are the same there exists 3
separate contact methods that increase
contactability (1*3=3)<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Today’s
preliminary agreements indicate that we could
end up with a single contact type (Registrant)
with a single contact method (email
address). i.e. 1*1=1<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">This
will clearly will decrease contactability – not
increase it. I think we have more work to do
here….<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Alex<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><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" target="_blank" moz-do-not-send="true">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" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<pre>-- <o:p></o:p></pre>
<pre>------------------------------------------------<o:p></o:p></pre>
<pre>"It is a disgrace to be rich and honoured<o:p></o:p></pre>
<pre>in an unjust state" -Confucius<o:p></o:p></pre>
<pre> <span style="font-family:"MS Gothic"">邦有道，</span><span style="font-family:"Microsoft JhengHei",sans-serif">贫且贱焉，耻也。邦无道，富且贵焉，耻也</span><o:p></o:p></pre>
<pre>------------------------------------------------<o:p></o:p></pre>
<pre>Dr Sam Lanfranco (Prof Emeritus & Senior Scholar)<o:p></o:p></pre>
<pre>Econ, York U., Toronto, Ontario, CANADA - M3J 1P3<o:p></o:p></pre>
<pre>email: <a href="mailto:Lanfran@Yorku.ca" target="_blank" moz-do-not-send="true">Lanfran@Yorku.ca</a> Skype: slanfranco<o:p></o:p></pre>
<pre>blog: <a href="https://samlanfranco.blogspot.com" target="_blank" moz-do-not-send="true">https://samlanfranco.blogspot.com</a><o:p></o:p></pre>
<pre>Phone: +1 613-476-0429 cell: +1 416-816-2852<o:p></o:p></pre>
</div>
<p class="MsoNormal">_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org"
target="_blank" moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a><br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a><o:p></o:p></p>
</blockquote>
</div>
</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" moz-do-not-send="true">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" moz-do-not-send="true">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" 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>