[gnso-rds-pdp-wg] authoritative
Volker Greimann
vgreimann at key-systems.net
Tue May 2 14:18:04 UTC 2017
Correct, but we can. Should we then have to treat an other (more remote)
source as more authoritative than our data?
Best,
Volker
Am 02.05.2017 um 16:16 schrieb Greg Aaron:
>
> Unfortunately the rest of the word can’t peer into your internal database.
>
> *From:*gnso-rds-pdp-wg-bounces at icann.org
> [mailto:gnso-rds-pdp-wg-bounces at icann.org] *On Behalf Of *Volker Greimann
> *Sent:* Tuesday, May 2, 2017 10:11 AM
> *To:* gnso-rds-pdp-wg at icann.org
> *Subject:* Re: [gnso-rds-pdp-wg] authoritative
>
> It really depends.
>
> The German trade register is authoritative in the latter sence since
> it can be relied upon by third parties, because there is legislation
> makes it authoritative in that sense.
>
> As a registrar, I do not check the whois for determining the ownership
> of a domain we manage, I check our own internal data (unless the
> registry allows direct modification by the registrant).
>
> There certainly is no legislation making the registry or the RDS
> output legally authoritative.
>
> And as for closeness to the source, nothing beats the registrar (or
> his resellers).
>
> Best,
>
> Volker
>
> Am 02.05.2017 um 16:04 schrieb Greg Aaron:
>
> Dear Paul:
>
> Hi. I suggest the latter. A registry contains data that is
> considered an official record.
>
> As I mentioned, accuracy is a related but separate issue. And
> bogus contact data is inaccurate no matter where it sits – at the
> registry or at the registrar.
>
> Other than contact data, the data in registries is accurate.
> Registries are the only place that records, authoritatively and
> accurately, what domains exist, what time each domain was entered
> into the registry and the term (and therefore the expiration
> date), the registrar of record, etc. They accurately record what
> nameservers a registrar designates for a domain, and because the
> registry is authoritative for that data those nameservers are the
> only ones the domain will resolve to.
>
> And registries accurately record what contact data the registrar
> placed on the record. That contact data may be inaccurate (even
> patently false), but it’s what’s on the official record, and from
> a legal perspective that has consequences.
>
> I am not sure what you mean when you say “there must be some
> verification process as between the registry and registrars. It
> is my understanding that this already exists”. The registrars
> have some data accuracy responsibilities as spelled out in the
> RAA, but how much accuracy they deliver is a separate
> conversation. At this time gTLD registries don’t verify the
> accuracy (truthfulness) of contact data that registrars put into
> the registry. Although some ccTLD registries (like .UK) have some
> checks.
>
> All best,
>
> --Greg
>
> *From:*Paul Keating [mailto:Paul at law.es]
> *Sent:* Tuesday, May 2, 2017 6:29 AM
> *To:* Greg Aaron <gca at icginc.com> <mailto:gca at icginc.com>; David
> Cake <dave at davecake.net> <mailto:dave at davecake.net>; Sam Lanfranco
> <sam at lanfranco.net> <mailto:sam at lanfranco.net>
> *Cc:* gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
> *Subject:* Re: [gnso-rds-pdp-wg] authoritative
>
> Greg,
>
> I want to make sure I am not confused.
>
> By “Authoritative” are we meaning that
>
> the data is most accurate (closest to the source)
>
> OR
>
> That it is the one to be relied upon regardless of how close it
> is/was to the originating source.
>
> If it is the former, then (a) it will originate at the registrar
> and (b) we must accept that it may or may not remember the truth
> (e.g. Be actually correct info as opposed to whatever the
> registrant provided).
>
> If the registries are to one the authoritative source then there
> must be some verification process as between the registry and
> registrars. It is my understanding that this already exists and
> that we were historically dealing with thin WHOIS as a result of
> historical structure of the original registry (which was at the
> time also a registrar). The other registrars did not want
> Verisign to have information about their customers for competitive
> reasons.
>
> And, of course for the purposes of the various privacy rules, it
> is the registrar as the collecting agent that must deal with the
> consent/permission issues relative to collection and use.
>
> My thoughts anyway.
>
> Paul Keating
>
> *From: *<gnso-rds-pdp-wg-bounces at icann.org
> <mailto:gnso-rds-pdp-wg-bounces at icann.org>> on behalf of Greg
> Aaron <gca at icginc.com <mailto:gca at icginc.com>>
> *Date: *Monday, May 1, 2017 at 6:42 PM
> *To: *David Cake <dave at davecake.net <mailto:dave at davecake.net>>,
> Sam Lanfranco <sam at lanfranco.net <mailto:sam at lanfranco.net>>
> *Cc: *"gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>" <gnso-rds-pdp-wg at icann.org
> <mailto:gnso-rds-pdp-wg at icann.org>>
> *Subject: *Re: [gnso-rds-pdp-wg] authoritative
>
> I think Sam and Scott are saying is that contact (thick) data
> in registries should never be relied upon. And since it
> can't, the logical conclusion is that we might as well return
> to thin registries, in which contact data is held only at
> registrars. In such a paradigm an RDS system could retrieve
> contact data for you from the distributed registrars, but
> there's no reason to store it in registries.
>
> All that is the opposite of what the GNSO's Thick WHOIS PDP
> recently reasoned.
>
> That PDP said that gTLD registries must be thick, in order to
> deliver a variety of benefits. That PDP WG also wrote that:
> "the only authoritative data source can be the registry as it
> holds the ultimate sway over the data. A registrar updates the
> data at customer request and is responsible for its accuracy,
> but such changes would only become authoritative once the
> registry Whois reflects the change."
>
> Below is the relevant section of The Thick WHOIS PDP final
> report. As always, our WG should avail itself of previous
> work on relevant issues -- so we don't reinvent the wheel when
> we don't have to, and we don't throw out good policy when we
> don't have to. Our WG should examine the Thick WHOIS PDP's
> reasoning, and I suggest that a deviation from it should be
> compelling.
>
> I have been using the meaning of "authoritative" that the PDP
> did below. David Cake, the below helps explain why the issue
> is important. As I said before, the validation of contact
> data -- whether it is truthful and accurate -- is a related
> but separate issue.
>
> https://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf
>
> “Issue Description
>
> Here is the working definition used by the WG while analysing
> this issue: "Authoritative, with respect to provision of Whois
> services, shall be interpreted as to signify the single
> database within a hierarchical database structure holding the
> data that is assumed to be the final authority regarding the
> question of which record shall be considered accurate and
> reliable in case of conflicting records; administered by a
> single administrative [agent] and consisting of data provided
> by the registrants of record through their registrars." A
> proposed shorter version is "the data set to be relied upon in
> case of doubt".
>
> Authoritativeness in a thin Whois environment
>
> Since the registrar alone holds most Whois data, its data is
> necessarily authoritative as to those data elements (e.g.,
> name of registrant). For that data held by both registrar and
> registry (e.g., name of registrar), it appears that registry
> data is generally treated as authoritative, but the WG is not
> aware of any official ICANN policy statement on this. The WG
> observes that in the case of the Uniform Dispute Resolution
> Policy (UDRP), UDRP Providers treat the registrar Whois
> information as authoritative, which may be the result of the
> UDRP having been adopted prior to the emergence of thick gTLD
> registries.
>
> Authoritativeness in a thick Whois environment
>
> Most comments that addressed this question stated that
> registry data is considered authoritative in the thick
> environment. Only one stated that the registrar data was
> authoritative. Again, the WG is not aware of any official
> ICANN policy statement on this question. The WG notes that the
> registrar remains responsible for the accuracy of the data
> under either the thick or thin model, as the relationship with
> the registrant remains with the registrar.
>
> Possible advantages for authoritativeness in a thick Whois
> environment
>
> Several comments cited efficiency and trust as advantages of
> treating the registry Whois data as authoritative. The WG
> supports the view that the registry will hold the entire data
> set, and is able to change the data without informing the
> registrar (due to closed court orders or similar events).
> Therefore, the only authoritative data source can be the
> registry as it holds the ultimate sway over the data. A
> registrar updates the data at customer request and is
> responsible for its accuracy, but such changes would only
> become authoritative once the registry Whois reflects the change.
>
> Possible downsides for authoritativeness in a thick Whois
> environment
>
> Several comments noted that registrars remain responsible for
> collecting the data and (to an extent governed by contract
> with ICANN) for its accuracy. One contribution felt this was
> inconsistent with a conclusion that registry Whois would be
> authoritative in the thick environment. The WG did not agree
> that this inconsistency was problematic (primarily on the
> grounds stated above that the WG that any data collected by
> the registrar becomes authoritative only after it is
> incorporated in the registry database).
>
> Conclusion
>
> The WG finds that a transition from thin to thick Whois will
> have no detrimental effect on authoritativeness. The WG
> reviewed the question as to whether it is necessary for this
> WG to recommend a policy on this issue. Based on that review,
> the WG has concluded that this is not necessary, given that
> thick registries have functioned for many years without
> requiring a formal position on authoritativeness, and the lack
> of evidence that this created any problem during previous
> thin-to-thick transitions such as .org."
>
> It falls to our RDS WG to create additional policy on this
> issue. I think that the logical policy is for registries to
> be thick, and the only authoritative data source can be the
> registry as it holds the ultimate sway over the data. A
> registrar updates the data at customer request and is
> responsible for its accuracy, but such changes would only
> become authoritative once the registry Whois reflects the change.
>
> 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 *David Cake
> *Sent:* Monday, May 1, 2017 11:55 AM
> *To:* Sam Lanfranco <sam at lanfranco.net <mailto:sam at lanfranco.net>>
> *Cc:* gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
> *Subject:* Re: [gnso-rds-pdp-wg] authoritative
>
> While I have no objection in the abstract to authoritative
> being used on the sense of ‘according to some recognised
> authority’, I’m not sure that is relevant to our discussions.
>
> I’m not aware of any external authority.that are discussing
> here, mostly it we were talking about validation it was
> validation against a process (such as ensuring email was
> valid) rather than validation
>
> to an external authority.
>
> I still believe that this sense of authoritative is NOT the
> same as the sense in which we origioonally used the rm within
> the requirements, and which prompted the current discussion,
> which is the data theoretic sense loosely congruent to the way
> the term is used within the DNS - which is to say, the best
> source of data *internal* to the system. An authoritative data
> source in that sense would be e.g. the registry direct, rather
> than a cache or by a proxy. And the ongoing confusion keeps
> bringing me back to you wanting to avoid the term if we can’t
> keep definitions straight for 5 minutes.
>
> David
>
> On 1 May 2017, at 8:56 pm, Sam Lanfranco
> <sam at lanfranco.net <mailto:sam at lanfranco.net>> wrote:
>
> From Paul Keating's posting and in terms of my comments:
>
> * here the adjective "authoritative" would not not mean
> "recognized as true, valid"
> * here the adjective "authoritative" would mean
> "official, authorized"
>
> The best that can be done here is to have official,
> authorized, Data of Record from a Source of Record.
> The struggle for data quality is an ongoing struggle,
> here, everywhere, and always.
>
> What the Data of Record data set consists of, and build
> with a sensitivity to purpose, seems to me to be the main
> rds-pdp-wg task here.
>
> As to who has access to what and under what terms, ICANN
> might set some terms there, but ultimately ICANN,
> as a stakeholder there will play an advisory role.
> National and multilateral policies will rule above ICANN
> policy.
>
> Sam L.
>
>
>
>
>
> _______________________________________________
> 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
>
>
>
>
> _______________________________________________
>
> 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/20170502/742f86e6/attachment-0001.html>
More information about the gnso-rds-pdp-wg
mailing list