<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">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"><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"><u></u><u></u></span></a></p>
<p class="MsoNormal"><span><span style="font-size:11.0pt"><u></u> <u></u></span></span></p>
<div>
<p class="MsoNormal"><span><span style="font-size:11.0pt">All best,<u></u><u></u></span></span></p>
<p class="MsoNormal"><span><span style="font-size:11.0pt">--Greg</span></span><span><span style="font-size:10.0pt"><u></u><u></u></span></span></p>
</div>
<p class="MsoNormal"><span><span style="font-size:11.0pt"><u></u> <u></u></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">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">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">gnso-rds-pdp-wg@icann.org</a><br>
<b>Subject:</b> [gnso-rds-pdp-wg] Contractibility, PBC
and required contact methods....<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">Hi
All,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <u></u><u></u></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"><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"> </span><span style="font-size:11.0pt;color:black"><u></u><u></u></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"><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"> </span><span style="font-size:11.0pt;color:black"><u></u><u></u></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"><u></u><u></u></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:black"> </span><span style="font-size:11.0pt;color:black"><u></u><u></u></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"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black"> </span><span style="font-size:11.0pt;color:black"><u></u><u></u></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"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black"> </span><span style="font-size:11.0pt;color:black"><u></u><u></u></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"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black"> </span><span style="font-size:11.0pt;color:black"><u></u><u></u></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"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black"> </span><span style="font-size:11.0pt;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:black">Alex</span><span style="font-size:11.0pt;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></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">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">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">Lanfran@Yorku.ca</a> Skype: slanfranco
blog: <a class="m_7827393201787179921moz-txt-link-freetext" href="https://samlanfranco.blogspot.com" target="_blank">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">gnso-rds-pdp-wg@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></blockquote></div></div>