[gnso-rds-pdp-wg] Proposed Agenda for RDS PDP WG Meeting Tuesday 25 April 16.00 UTC

[Paul Keating]

Volker, 

No insult intended but I believe you are making an error because you are
(IMHO) approaching the ³problem² using the narrow set of use-case-facts you
may know..


> Volker Greimann vgreimann at key-systems.net wrote:  example, but Whois not
> necessarily needed for that. Each company could just have asked their
> registrars to certify their ownership of the domain names. Most registrars
> provide this service if asked, either for a fee or as included part of their
> management services. These certifications could then be handed to the
> "opposing" counsel.
> 
As an attorney having engaged in m any similar transactions, I can assure
you that obtaining a certificate of ownership and being able to investigate
WHOIS, including historical information via aggregators, it is NOT at all
the same.

Case 1. As a seller I must represent and warrant that I have good and
marketable title and own the asset free of claims and encumbrances.
Depending upon the value of the domain name, the client may require that the
historical ownership be verified and compared with acquisition records so as
to determine a clean history of title (the same a title company does when
you purchase real estate).

Case 2. I represent auditing companies and must establish the accuracy of
transactional records evidencing purchase.  To do so I must access a third
party source (independent of the client).  Thus, I turn to WHOIS aggregators
who maintain historical information that can be used to verify ownership
against the purchase documentation.

Case 3. I am representing a client faced with a tax audit.  I must establish
by independent means the acquisition of the domain name(s).

Case 4. I am assisting a client recover a domain name that has been
highjacked.  The WHOIS, both current and historical provides extremely
valuable data without which I could not accomplish my task.

In all of the above, the domain may have been registered at various
registrars during its life.  My client may not even know all of the
registrars in the title history (e.g. Some may have been automated or prior
to ownership).  Those client who acquire via the drop often have 10¹s ­ 20¹s
registrar accounts and although they attempt to consolidate that is not an
easy task.  So, merely asking my client¹s current registrar for data is a
no-go.

Further, using your ³system² I must pay each point of data requests ­ surely
the registrars will attempt to create a revenue model ­ something I suspect
they want all along and is a major driver for them in this issue.  So,
instead of dealing with an automated task with a single purchase transaction
point I must now deal with a manual process with multiple transaction
points.




From:  <gnso-rds-pdp-wg-bounces at icann.org> on behalf of Volker Greimann
<vgreimann at key-systems.net>
Date:  Friday, April 28, 2017 at 11:59 AM
To:  <gnso-rds-pdp-wg at icann.org>
Subject:  Re: [gnso-rds-pdp-wg] Proposed Agenda for RDS PDP WG Meeting
Tuesday 25 April 16.00 UTC

>     
>  
> 
> 
>  
>  
>  
>>  
>>  
>> As another use case, a recent merger of two companies created a company with
>> a combined portfolio of approximately 7000 domain names.  In the course of
>> preparation and due diligence for the transaction, the law firms working on
>> the merger probably both accessed the Whois records for all those domain
>> names, as well as receiving reports from the registrars.  The law firms may
>> have accessed them directly, or through a service like DomainTools.  Some of
>> these were almost certainly ccTLDs but I would guess the vast majority were
>> gTLDs.
>>  
>> 
>>  
>>  
>>  
>  Good example, but Whois not necessarily needed for that. Each company could
> just have asked their registrars to certify their ownership of the domain
> names. Most registrars provide this service if asked, either for a fee or as
> included part of their management services. These certifications could then be
> handed to the "opposing" counsel.
>  
>  Volker
>  
>  
>  
>>  
>> 
>>  
>> 
>>  
>>  
>>  
>>  
>> On Wed, Apr 26, 2017 at 7:51 PM, Anderson, Marc <mcanderson at verisign.com>
>> wrote:
>>  
>>>  
>>>  
>>>  
>>> 
>>> Greg, my apologies for misquoting you, please consider me corrected.
>>>  
>>>  
>>>  
>>> I don¹t think that a future RDS that facilitates access to the BPS of data
>>> rather than a one stop aggregator of data (which comes with synchronization
>>> and update challenges) would create a tsunami.  After all this is how the
>>> DNS works today and it has much higher volumes than RDS.  That said you make
>>> a fair point about possible unintended consequences and not letting perfect
>>> be the enemy of the good.
>>>  
>>>  
>>>  
>>> I would be interested in hearing more about the registrar that needs access
>>> to 10k plus whois records a day.  Has that use case been accounted for in
>>> the list of potential RDS requirements the working group has collected?
>>>  
>>>  
>>>  
>>> Thanks,
>>>  Marc
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>> From: Greg Shatan [mailto:gregshatanipc at gmail.com]
>>>  Sent: Wednesday, April 26, 2017 3:16 PM
>>>  To: Anderson, Marc
>>>  Cc: Gomes, Chuck; gtheo at xs4all.nl; gnso-rds-pdp-wg at icann.org
>>>  
>>>  
>>> 
>>>  Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] Proposed Agenda for RDS PDP WG
>>> Meeting Tuesday 25 April 16.00 UTC
>>>  
>>>  
>>>  
>>>  
>>> 
>>>  
>>>  
>>>  
>>>  
>>> 
>>> Marc,
>>>  
>>>  
>>>  
>>> 
>>>  
>>>  
>>>  
>>>  
>>> 
>>> I don't think the importance of convenience or "one-stop" to information
>>> related to the registration should be underestimated.  I have heard that one
>>> registrar I know of accesses approximately 10,000 WHOIS records a day.
>>> Slicing and dicing the data currently in WHOIS could have massive ripple
>>> effects (maybe tsunami effects is more appropriate), if one look-up now
>>> becomes several look-ups later.  The possible split between thin and thick
>>> is bad enough.
>>>  
>>>  
>>>  
>>> 
>>>  
>>>  
>>>  
>>>  
>>> 
>>> Also, if some of the data is taken from the best possible (avoiding
>>> "authoritative") source (BPS), rather than the RDS database being the best
>>> possible source, then that should be explained and understood.  Methods for
>>> insuring the highest fidelity to the BPS should be put in place, and the
>>> gaps should be generally explained and understood (e.g., if the RDS and the
>>> BPS only sync once a day or once an hour that should be understood, so that
>>> if you need absolutely current information from the BPS, you may need to go
>>> to the BPS as well).
>>>  
>>>  
>>>  
>>> 
>>>  
>>>  
>>>  
>>>  
>>> 
>>> Whatever we do, there will still be some know-how and tricks of the trade,
>>> but we shouldn't let the perfect be the enemy of the good.
>>>  
>>>  
>>>  
>>> 
>>>  
>>>  
>>>  
>>>  
>>> 
>>> Finally, to be clear, your statement, based on my statement, isn't quite
>>> accurate (e.g., my email would be the BPS...).
>>>  
>>>  
>>>  
>>> 
>>> You said,  "As has been pointed out in another thread, this isn¹t just the
>>> ³Privacy Working Group²; it¹s the ³Next Gen RDS Working Group²."
>>>  
>>>  
>>>  
>>> 
>>> It would be a more accurate paraphrase to say, "As has been pointed out in
>>> another thread, this isn¹t the ³Privacy Working Group²; it¹s just the ³Next
>>> Gen RDS Working Group²."
>>>  
>>>  
>>>  
>>> 
>>>  
>>>  
>>>  
>>>  
>>> 
>>> Greg
>>>  
>>>  
>>>  
>>>  
>>> 
>>> 
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>> 
>>> Greg Shatan
>>>  C: 917-816-6428 <tel:%28917%29%20816-6428>
>>>  S: gsshatan
>>>  Phone-to-Skype: 646-845-9428 <tel:%28646%29%20845-9428>
>>>  gregshatanipc at gmail.com <mailto:gregshatanipc at gmail.com>
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>> 
>>>  
>>>  
>>>  
>>> 
>>> On Wed, Apr 26, 2017 at 2:15 PM, Anderson, Marc via gnso-rds-pdp-wg
>>> <gnso-rds-pdp-wg at icann.org> wrote:
>>>  
>>>  
>>>  
>>> 
>>> Chuck, I didn¹t do a very good job explaining my hesitation on yesterday¹s
>>> call so let me try again here.
>>>  
>>>  
>>>  
>>> I appreciate that we¹ve gotten bogged down recently and that the leadership
>>> team is trying to move the PDP forward.  From my perspective though, we went
>>> from trying to define a purpose(s) of RDS and discussing what data elements
>>> should be collected (making sure they map back to a purpose) and then
>>> defining who should have access to those data elements and under what
>>> circumstances to just throwing up our hands and saying hey, the elements of
>>> today¹s ³thin² whois don¹t seem to have any personally identifiable
>>> information in them, does anyone object to just making it all available for
>>> unlimited anonymous access in a future RDS solution.
>>>  
>>>  
>>>  
>>> When you asked if anyone objects I felt left with a choice: either say
>>> nothing which would in effect be agreeing that this working group has
>>> reached rough consensus that all of today¹s ³thin² whois elements should
>>> continue to be available via unlimited anonymous access or object.  While
>>> I¹m not sure exactly what I would have been agreeing to by remaining silent
>>> I don¹t feel comfortable saying that existing thin whois should continue as
>>> is.
>>>  
>>>  
>>>  
>>> On a previous call we discussed the Registrar field and if that should be
>>> required or not.  We ran out of time before fully getting into the
>>> discussion.  Aside from the ³Sponsoring Registrar IANA ID² field, I don¹t
>>> think it makes sense to require other registrar meta data in a domain query
>>> response.  For example the Whois Server, Referral URL and (newly required)
>>> Registrar abuse phone and Registrar abuse email fields.  These are all
>>> registrar specific data elements not domain data elements.  If querying a
>>> registrar RDS service, you already know the whois server and referral URL so
>>> it really doesn¹t make sense to have those in the response.
>>>  
>>> As ICANN accredits registrars and already maintains public lists of them, to
>>> me it makes more sense to have that data centrally managed/maintained and
>>> made available by ICANN.  At risk of pre-supposing a solution, RDAP would
>>> provide the ability to bring that data together in a single client pulling
>>> from separate (more appropriate) data sources.
>>>  
>>>  
>>>  
>>> I have questions about other fields as well.  Name Server information for
>>> example is already available via DNS.  There is undoubtedly a convenience
>>> factor to being able to get that from whois as well.  I know that
>>> authoritative is a loaded term but in the event that whois and DNS were
>>> different I don¹t think anyone would consider whois authoritative using any
>>> definition of the term.  Shouldn¹t we consider if it makes sense to continue
>>> to provide the same domain data elements in two different places?
>>>  
>>>  
>>>  
>>> Domain statuses have been discussed a little bit by this working group but
>>> to my knowledge not in detail.  From what I¹ve heard so far I¹m not sure
>>> that data should be available to anyone other than the registrar and
>>> registrant.  I¹m not saying there isn¹t a valid use case, but unless I
>>> missed it, I don¹t think we¹ve really had a chance to discuss, much less
>>> come to consensus.
>>>  
>>>  
>>>  
>>> Again I realize we are trying to move things forward and if the intent is to
>>> table some of these discussions so we can get to the gated access
>>> discussion, I get it.  It felt to me on the call though that we had boiled
>>> things down to since there is no personally identifiable information in
>>> traditional thin whois, let¹s just have all of that be available for
>>> unlimited anonymous access.  As has been pointed out in another thread, this
>>> isn¹t just the ³Privacy Working Group²; it¹s the ³Next Gen RDS Working
>>> Group².
>>>  
>>>  
>>>  
>>> Hopefully that helps explain my hesitation and why I put a red ³X² in Adobe.
>>>  
>>>  
>>>  
>>> Thanks,
>>>  
>>> Marc
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>> 
>>> From: gnso-rds-pdp-wg-bounces at icann.org
>>> [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Gomes, Chuck via
>>> gnso-rds-pdp-wg
>>>  Sent: Tuesday, April 25, 2017 6:02 PM
>>>  To: gtheo at xs4all.nl;  gnso-rds-pdp-wg at icann.org
>>> <mailto:gnso-rds-pdp-wg at icann.org>
>>>  
>>>  
>>>  
>>> 
>>> 
>>>  Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] Proposed Agenda for RDS PDP WG
>>> Meeting Tuesday 25 April 16.00 UTC
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>> 
>>>  
>>>  
>>> Thanks Theo.  Do I understand you are saying that you could support thin
>>> Whois data elements as public data in the RDS?
>>>  
>>>  
>>>  
>>> Regardless, I would still like to see if we can find a resolution to Marc¹s
>>> concern as long as we don¹t spend an inordinate amount of time on it.  I
>>> will try to reach out to Marc to see if I can understand his position
>>> better.  And the Leadership team will try to schedule a call later this week
>>> to work on this further.
>>>  
>>>  
>>>  
>>> Chuck
>>>  
>>>  
>>>  
>>>  
>>>  
>>> 
>>> From: gnso-rds-pdp-wg-bounces at icann.org
>>> [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of theo geurts
>>>  Sent: Tuesday, April 25, 2017 2:31 PM
>>>  To: gnso-rds-pdp-wg at icann.org
>>>  Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] Proposed Agenda for RDS PDP WG
>>> Meeting Tuesday 25 April 16.00 UTC
>>>  
>>>  
>>>  
>>>  
>>>  
>>> Repeating my agreement with the below as mentioned earlier on the call.
>>>  
>>>  Regarding my earlier comments about NO WHOIS, still technically feasible,
>>> and in my opinion good to think outside of the box and check what the
>>> purpose is, and I think we should keep checking the purpose all the time.
>>> For the progress of the WG, it is best to move to gated access and use thin
>>> WHOIS for now as available public data.
>>>  
>>>  For the discussion about gated access perhaps it is an idea look at the
>>> IPC/RrSG developed framework for the PPSAI to see if that is sufficient to
>>> address copyright and trademark concerns. Could save us work if that is
>>> workable. 
>>>  
>>>  Best,
>>>  
>>>  Theo Geurts
>>>  
>>>  
>>> 
>>> On 25-4-2017 16:40, Victoria Sheckler wrote:
>>>  
>>>  
>>>>  
>>>> Apologies for missing last week¹s and today¹s meeting.  With respect to
>>>> item 4 below, based on the discussion we¹ve had to date, I believe all thin
>>>> whois data should be publicly available as it is either not personally
>>>> identifiable information, or, in extreme edge cases (such as a long domain
>>>> name that includes personal information), then it is clear that that
>>>> individual has chosen to make such information public.
>>>>  
>>>>  
>>>>  
>>>>  
>>>>  
>>>> 
>>>> From: gnso-rds-pdp-wg-bounces at icann.org
>>>> [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Lisa Phifer
>>>>  Sent: Monday, April 24, 2017 12:51 PM
>>>>  To: RDS PDP WG <gnso-rds-pdp-wg at icann.org>
>>>> <mailto:gnso-rds-pdp-wg at icann.org>
>>>>  Subject: [gnso-rds-pdp-wg] Proposed Agenda for RDS PDP WG Meeting Tuesday
>>>> 25 April 16.00 UTC
>>>>  
>>>>  
>>>>  
>>>>  
>>>>  
>>>> Dear all,
>>>>  
>>>>  The next GNSO Next-Gen RDS PDP Working Group teleconference will take
>>>> place on  Tuesday, 25 April at  16.00 UTC
>>>>  
>>>>  Below please find the proposed agenda for this meeting, along with links
>>>> to meeting materials, which can all be found on the meeting page:
>>>> https://community.icann.org/x/DcPRAw
>>>>  
>>>>   <https://community.icann.org/x/DcPRAw> Regards,
>>>>  Lisa
>>>>  
>>>>  Proposed Agenda for RDS PDP WG Meeting 25 April 16.00 UTC
>>>>  1) Roll Call/SOI Updates
>>>>  2) Plan to complete in-progress tasks
>>>>      a) ccTLD questions
>>>>      b) Definition of authoritative
>>>>  3) Revised Task 12 sequence and timeline
>>>>      See  RDSPDP-Task12-Revised-21April2017.pdf
>>>> <https://community.icann.org/download/attachments/56986784/RDSPDP-Task12-Re
>>>> vised-21April2017.pdf?version=1&modificationDate=1492802630734&api=v2>
>>>>  4) Start deliberation on the charter question/subquestion 5.1:
>>>>      Should gTLD registration "thin data" be entirely public or should
>>>> access be controlled?
>>>>      See  NewSection5-Intro-KeyConcepts-21April2017.pdf
>>>> <https://community.icann.org/download/attachments/64078605/NewSection5-Intr
>>>> o-KeyConcepts-21April2017.pdf?version=1&modificationDate=1492802791000&api=
>>>> v2> 
>>>>  5) Confirm action items and proposed decision points
>>>>  6) Confirm next meeting date: 2 May 2017 at 16:00 UTC
>>>>   
>>>>  Meeting Materials:  https://community.icann.org/x/DcPRAw
>>>> <https://community.icann.org/x/DcPRAw>
>>>>  
>>>>  
>>>>  
>>>> _______________________________________________
>>>> gnso-rds-pdp-wg mailing list
>>>> 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.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-
>>> wg
>>>  
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> 
gnso-rds-pdp-wg at icann.orghttps://mm.icann.org/mailman/listinfo/gnso-rds-pdp-w>>
g
> -- 
> 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 <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
> 
> 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.
> 
> 
> 
> _______________________________________________ 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/20170428/1f262b67/attachment-0001.html>