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

[Greg Shatan]

I share and support Alex's concerns here.  I think it helps to unpack the
two issues here and deal with them discretely.

1. The number of contact methods and whether each is mandatory or optional.
2. The number of contact types.

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.

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.

Greg



On Thu, Aug 24, 2017 at 11:10 AM Sam Lanfranco <sam at lanfranco.net> wrote:

> 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
> <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 listgnso-rds-pdp-wg at icann.orghttps://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
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170824/33b4b562/attachment.html>