[gnso-rds-pdp-wg] Contractibility, PBC and required contact methods....
Volker Greimann
vgreimann at key-systems.net
Fri Aug 25 09:11:25 UTC 2017
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?
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.
Best,
Volker
Am 24.08.2017 um 18:15 schrieb Greg Aaron:
>
> 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.
>
> That’s why the UDRP requires:
>
> “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
>
> (ii) sending the complaint, including any annexes, in electronic form
> by e-mail to:
>
> (A) the e-mail addresses for those technical, administrative, and
> billing contacts;
>
> (B) postmaster@<the contested domain name>; and
>
> (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”
>
> Such requirements are there to protect registrants and provide a good
> process.
>
> The “digital nomad” is yet another corner case.
>
> All best,
>
> --Greg
>
> *From:*gnso-rds-pdp-wg-bounces at icann.org
> [mailto:gnso-rds-pdp-wg-bounces at icann.org] *On Behalf Of *Volker Greimann
> *Sent:* Thursday, August 24, 2017 11:41 AM
> *To:* gnso-rds-pdp-wg at icann.org
> *Subject:* Re: [gnso-rds-pdp-wg] Contractibility, PBC and required
> contact methods....
>
> 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.
>
> 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.
>
> 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.
>
> Best,
>
> Volker
>
> Am 24.08.2017 um 17:28 schrieb 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
> <mailto: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>
> [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
> <mailto: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 <mailto: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 <mailto: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 <mailto:gnso-rds-pdp-wg at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
>
>
>
> _______________________________________________
>
> gnso-rds-pdp-wg mailing list
>
> gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
>
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
>
>
> --
> 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:vgreimann at key-systems.net <mailto:vgreimann at key-systems.net>
> Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net>
> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
> Geschäftsführer: Alexander Siffrin
> Handelsregister Nr.: HR B 18835 - Saarbruecken
> Umsatzsteuer ID.: DE211006534
> Member of the KEYDRIVE GROUP
> www.keydrive.lu <http://www.keydrive.lu>
> 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:vgreimann at key-systems.net <mailto:vgreimann at key-systems.net>
> Web:www.key-systems.net <http://www.key-systems.net> /www.RRPproxy.net <http://www.RRPproxy.net>
> www.domaindiscount24.com <http://www.domaindiscount24.com> /www.BrandShelter.com <http://www.BrandShelter.com>
> Follow us on Twitter or join our fan community on Facebook and stay updated:
> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
> CEO: Alexander Siffrin
> Registration No.: HR B 18835 - Saarbruecken
> V.A.T. ID.: DE211006534
> Member of the KEYDRIVE GROUP
> www.keydrive.lu <http://www.keydrive.lu>
> 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.
--
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: vgreimann at key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 18835 - Saarbruecken
Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
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: vgreimann at key-systems.net
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems
www.twitter.com/key_systems
CEO: Alexander Siffrin
Registration No.: HR B 18835 - Saarbruecken
V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP
www.keydrive.lu
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170825/0f76446b/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list