<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<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. <br>
</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. <br>
</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.</p>
<p>Best,</p>
<p>Volker<br>
</p>
<br>
<div class="moz-cite-prefix">Am 24.08.2017 um 17:28 schrieb Greg
Shatan:<br>
</div>
<blockquote type="cite"
cite="mid:CA+aOHUTotWmbuU3U5XnFxN5gYSYQW-0A-6icm7QhVS9PjGWzTg@mail.gmail.com">
<div>
<div dir="auto">I share and support Alex's concerns here. I
think it helps to unpack the two issues here and deal with
them discretely.</div>
<div dir="auto"><br>
</div>
<div dir="auto">1. The number of contact methods and whether
each is mandatory or optional.</div>
<div dir="auto">2. The number of contact types.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Greg</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<br>
<div class="gmail_quote">
<div>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:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> I don't know if this
helps, but at least it is a short read:<br>
<br>
<p class="MsoNormal">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. <br>
</p>
<p class="MsoNormal"><br>
</p>
<p class="MsoNormal">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. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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. <br>
</p>
<p class="MsoNormal"><br>
</p>
<p class="MsoNormal">What are the WG decision issues here?
Tentatively we have the six PBCs.</p>
<p class="MsoNormal"><br>
</p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal">We decide on X mandatory contact
options. For each PBC there are X possible choices. </li>
<li class="MsoNormal">We decide on Y optional options,
so for each PBC there are between one and (X+Y)
contact choices. <br>
</li>
<li class="MsoNormal">We decide on what are acceptable
contact option formats.</li>
<li class="MsoNormal">With 6 contact purposes there
should be 6 fields for contact options.</li>
</ul>
<p class="MsoNormal">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. <br>
</p>
<p class="MsoNormal"><br>
</p>
<p class="MsoNormal">For what it is worth....</p>
<p class="MsoNormal"><br>
</p>
<p class="MsoNormal">Sam L. <br>
</p>
</div>
<div text="#000000" bgcolor="#FFFFFF"> <br>
<br>
<div class="m_7827393201787179921moz-cite-prefix">On
8/24/2017 8:49 AM, Greg Aaron wrote:<br>
</div>
<blockquote type="cite">
<div class="m_7827393201787179921WordSection1">
<p class="MsoNormal"><a
name="m_7827393201787179921__MailEndCompose"
moz-do-not-send="true"><span
style="font-size:11.0pt">Yes – there appears to
be inconsistency between the goal of decent
contactability and the possible implementation,
which might not deliver on that promise.</span><span
style="color:black"></span></a></p>
<p class="MsoNormal"><span><span
style="font-size:11.0pt"> </span></span></p>
<div>
<p class="MsoNormal"><span><span
style="font-size:11.0pt">All best,</span></span></p>
<p class="MsoNormal"><span><span
style="font-size:11.0pt">--Greg</span></span><span><span
style="font-size:10.0pt"></span></span></p>
</div>
<p class="MsoNormal"><span><span
style="font-size:11.0pt"> </span></span></p>
<span></span>
<div>
<div style="border:none;border-top:solid #e1e1e1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:11.0pt">From:</span></b><span
style="font-size:11.0pt"> <a
class="m_7827393201787179921moz-txt-link-abbreviated"
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
class="m_7827393201787179921moz-txt-link-freetext"
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
class="m_7827393201787179921moz-txt-link-abbreviated"
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....</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span
style="font-size:11.0pt;color:black">Hi All,</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;color:black"> </span></p>
<p class="MsoNormal"><span style="color:black">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.</span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span
style="color:black"> </span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal" style="margin-left:.5in"><b><span
style="color:black">Preliminary WG Agreement:</span></b><span
style="color:black"> 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.</span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span
style="color:black"> </span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal" style="margin-left:.5in"><b><span
style="color:black">Preliminary WG Agreement:</span></b><span
style="color:black"> PBC types identified (Admin,
Legal, Technical, Abuse, Proxy/Privacy, Business)
must be supported by the RDS but optional for
registrants to provide</span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span
style="color:black"> </span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal"><span style="color:black">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. </span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal"><span style="color:black"> </span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal"><span style="color:black">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)</span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal"><span style="color:black"> </span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal"><span style="color:black">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</span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal"><span style="color:black"> </span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal"><span style="color:black">This
will clearly will decrease contactability – not
increase it. I think we have more work to do
here….</span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal"><span style="color:black"> </span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal"><span style="color:black">Alex</span><span
style="font-size:11.0pt;color:black"></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
</div>
<br>
<fieldset
class="m_7827393201787179921mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
gnso-rds-pdp-wg mailing list
<a class="m_7827393201787179921moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org" target="_blank" moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a>
<a class="m_7827393201787179921moz-txt-link-freetext" 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></pre>
</blockquote>
<br>
</div>
<div text="#000000" bgcolor="#FFFFFF">
<pre class="m_7827393201787179921moz-signature" cols="72">--
------------------------------------------------
"It is a disgrace to be rich and honoured
in an unjust state" -Confucius
邦有道，贫且贱焉，耻也。邦无道，富且贵焉，耻也
------------------------------------------------
Dr Sam Lanfranco (Prof Emeritus & Senior Scholar)
Econ, York U., Toronto, Ontario, CANADA - M3J 1P3
email: <a class="m_7827393201787179921moz-txt-link-abbreviated" href="mailto:Lanfran@Yorku.ca" target="_blank" moz-do-not-send="true">Lanfran@Yorku.ca</a> Skype: slanfranco
blog: <a class="m_7827393201787179921moz-txt-link-freetext" href="https://samlanfranco.blogspot.com" target="_blank" moz-do-not-send="true">https://samlanfranco.blogspot.com</a>
Phone: +1 613-476-0429 cell: +1 416-816-2852</pre>
</div>
_______________________________________________<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"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
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>