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

Thu Aug 24 15:36:45 UTC 2017

There are those of us with expertise who have repeatedly voice in this
list that even "fake" data is useful to us. For instance, I can use the
same "fake data" to correlate the activities of a malicious individual
proactively... for instance, the technique we have used to track US
election influence operations, operations targeted against the French
elections, and any activity we may find targeting the German elections.
It can be used to "score" domains based on suspiciousness so *I* can
decide who connects to *my* network. In short, even fake data can help
us ensure the safety and stability of the internet which is a core goal
and purpose of ICANN.

As long as one contact is mandatory, I don't much care if the rest is
optional. Either way, when people make a choice, I can put on my
intelligence analyst hat and figure out more about them if they
otherwise merit my attention.

On 8/24/2017 10:32 AM, Volker Greimann wrote:
>
> We should also consider that while the presence of these three fields
> is currently mandatory, they can simply be filled with the registrants
> own data, so their usefulness is limited to the extend that their use
> for their actually intended purpose has become voluntary.
>
> Does it really make any difference for anyone to have seperate
> Registrant, Admin and Tech contacts if they all hold the same data? Is
> not filling them with the same data the same as omitting the latter
> two altogether? So why not make them completely voluntary and couple
> that with the understanding that if they are omitted the registrant
> (or his agent) takes on these functions as well.
>
> Best,
>
> Volker
>
>
> Am 24.08.2017 um 16:50 schrieb Sam Lanfranco:
>> 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
>>
>>
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> 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
>
> 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.
>
>
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

-- 
--

John Bambenek

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