[gnso-rds-pdp-wg] Contractibility, PBC and required contact methods....

Thu Aug 24 14:50:07 UTC 2017

I don't know if this helps, but at least it is a short read:

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.

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.

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.

What are the WG decision issues here? Tentatively we have the six PBCs.

  * We decide on X mandatory contact options. For each PBC there are X
    possible choices.
  * We decide on Y optional options, so for each PBC there are between
    one and (X+Y) contact choices.
  * We decide on what are acceptable contact option formats.
  * With 6 contact purposes there should be 6 fields for contact options.

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.

For what it is worth....

Sam L.

On 8/24/2017 8:49 AM, Greg Aaron wrote:
>
> Yes – there appears to be inconsistency between the goal of decent 
> contactability and the possible implementation, which might not 
> deliver on that promise.
>
> All best,
>
> --Greg
>
> *From:*gnso-rds-pdp-wg-bounces at icann.org 
> [mailto:gnso-rds-pdp-wg-bounces at icann.org] *On Behalf Of *Deacon, Alex
> *Sent:* Wednesday, August 23, 2017 2:56 PM
> *To:* gnso-rds-pdp-wg at icann.org
> *Subject:* [gnso-rds-pdp-wg] Contractibility, PBC and required contact 
> methods....
>
> Hi All,
>
> 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.
>
> *Preliminary WG Agreement:* 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.
>
> *Preliminary WG Agreement:* PBC types identified (Admin, Legal, 
> Technical, Abuse, Proxy/Privacy, Business) must be supported by the 
> RDS but optional for registrants to provide
>
> 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.
>
> 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)
>
> 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
>
> This will clearly will decrease contactability – not increase it.   
>   I think we have more work to do here….
>
> Alex
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

-- 
------------------------------------------------
"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: Lanfran at Yorku.ca   Skype: slanfranco
blog:  https://samlanfranco.blogspot.com
Phone: +1 613-476-0429 cell: +1 416-816-2852

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170824/850070c5/attachment-0001.html>