[gnso-rds-pdp-wg] authoritative

Greg Aaron gca at icginc.com
Mon May 1 14:13:34 UTC 2017


Folks are discussing the original source of data, and the repositories of data.  For a domain record, some (not all) data starts with a registrant.  Some data in a domain record is collected from the registrant by a registrar (the first repository of that data).  Some of that data is then placed in the registry (the second repository).   And some data in a domain record is created and held originally at the registry.



For legal purposes, and for some technical purposes, the definition of “authoritative” is the fourth (and maybe also third) definition that Paul gave.  That meaning of “authoritative” is: what is to be relied upon as the data of record, what is official, what rules if there’s a discrepancy.   This setup answers questions like: who’s the registrant of record?  What nameservers does this domain resolve to?  When does the domain expire?



In practical terms, “what data is to be relied upon, what is official, what rules” resides in the registry.  Certainly for thin data, and I think also for thick data in a thick regime, which is what ICANN has been moving to.



Registries exist to be authoritative repositories of data; that’s is their function and what they are designed to do.  (So, for example, two different people can’t register the same domain name, or so a domain won’t resolve to the wrong nameservers.)  Domain registries are generally considered authoritative for at least the thin data.  (Domain, sponsoring registrar, dates, statuses, nameservers.)  The registry creates or is the repository of record for most of those fields (domain, sponsoring registrar, dates).  And the registry is authoritative for status and nameserver data, using them to enable and control resolution, or to prevent certain actions from taking place in the registry (such as deletions, and registrar-to-registrar transfers). Registries are the ones that publish TLD zone files; that is one of their core functions.



The Thick WHOIS PDP decided that all gTLD registries should be thick.  One reason was to ensure that there won’t be any more disagreements (discrepancies)  between what the registrar says the data is and what the registry says it is (and as seen via WHOIS or a successor system).  Another reason was to hold contact data in one place reliably, so it could be served from one (to-be-trusted) place and can be escrowed reliably; as a consequence registrar port 43 WHOIS service will eventually go away.



So the current situation seems to be pretty simple, and is on the path to getting even simpler:

1.            If the registry is thick, the registry is authoritative (to be relied upon, official) for all data we see in WHOIS today.

2.            If the registry is thin, the registry is authoritative (to be relied upon, official) for the thin data, and the contact data held by the registrar is authoritative (to be relied up[on, official).  The remaining thin registries will go thick in a couple of years, which makes things simpler.



In other words, all registries should be considered authoritative (to be relied upon, official) for all the data we see in WHOIS, if they are not already.  That was the desired policy and operational outcome.  It is also the most practical and elegant solution.



The above has nothing to do with the accuracy (truthfulness) of contact data.  That’s a related but separate issue.



All best,

--Greg



(P.S.: the UDRP Rules say that the contact data in the “Registrar’s WHOIS” must be relied upon for proceedings (i.e. the registrar is authoritative for  contact data).  That was written in 1999, back before thick gTLD registries even existed.  I believe that language should eventually be changed to meet evolving reality.  In )




From: gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Paul Keating
Sent: Monday, May 1, 2017 8:34 AM
To: Hollenbeck, Scott <shollenbeck at verisign.com>
Cc: gnso-rds-pdp-wg at icann.org
Subject: Re: [gnso-rds-pdp-wg] authoritative

Authoritative is an adjective and thus relative by definition.

One source can be more or less authoritative than another.

Main Entry: source
Part of Speech: noun
Definition: beginning; point of supply
Synonyms: antecedent, author, authority, authorship, begetter, birthplace, cause, commencement, connection, dawn, dawning, derivation, determinant, expert, father, fount, fountain, fountainhead, horse's mouth, inception, informant, maternity, mother, onset, opening, origin, origination, originator, parent, paternity, provenance, provenience, rise, rising, root, specialist, spring, start, starting point, wellspring
Antonyms: effect, end, result




Main Entry: authoritative
Part of Speech: adjective
Definition: recognized as true, valid
Synonyms: accurate, attested, authentic, authenticated, circumstantiated, confirmed, definitive, dependable, documented, factual, faithful, learned, legit, proven, reliable, righteous, scholarly, sound, straight from horse's mouth, supported, trustworthy, truthful, validated, verified, veritable
Antonyms: democratic
Main Entry: authoritative
Part of Speech: adjective
Definition: domineering
Synonyms: assertive, authoritarian, autocratic, commanding, confident, decisive, dictatorial, doctrinaire, dogmatic, dominating, imperative, imperious, imposing, masterly, officious, peremptory, self-assured
Antonyms: democratic
Main Entry: authoritative
Part of Speech: adjective
Definition: official, authorized
Synonyms: administrative, approved, bureaucratic, canonical, departmental, ex cathedra, ex officio, executive, imperial, lawful, legal, legitimate, magisterial, mandatory, ruling, sanctioned, sovereign, supreme
Antonyms: democratic

Sincerely,
Paul Keating, Esq.

On May 1, 2017, at 1:51 PM, Hollenbeck, Scott via gnso-rds-pdp-wg <gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>> wrote:
On an alternative to "authoritative": I prefer to use word that means something along the lines of "closest to the original producer or collector", applying the concept of provenance (information about the creation, chain of custody, modifications or influences pertaining to an artifact) to data. One possible alternative might be "definitive".

Scott


-----Original Message-----
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<mailto:bounces at icann.org>] On Behalf Of Gomes, Chuck via gnso-rds-pdp-wg
Sent: Sunday, April 30, 2017 5:07 PM
To: dave at davecake.net<mailto:dave at davecake.net>; gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
Subject: [EXTERNAL] Re: [gnso-rds-pdp-wg] authoritative

In preparation for the WG meeting this coming Tuesday, I ask all members
to read David's message below and any messages on the list in response to
it.  We will try to reach at least a tentative conclusion on this in that
meeting.

Realizing that I temporarily halted discussion of issues on the list on
Friday, because this is really a definition of terminology and not really
an issue of requirements, if anyone has a suggestion for an alternative
term instead of 'authoritative', it would be okay to share it on the list.
Thanks to those of you who already responded.

Chuck

-----Original Message-----
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<mailto:bounces at icann.org>] On Behalf Of David Cake
Sent: Thursday, April 27, 2017 1:12 PM
To: RDS PDP WG <gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>>
Subject: [EXTERNAL] [gnso-rds-pdp-wg] authoritative

       I want to just write an (overdue) email recording what I
verbalising reported to the meeting earlier this week.
The small group looking at the term ‘authoritative’ and its definition
concluded that the term was best avoided.
Essentially, we identified three ways in which the term was in use, and
concluded that the potential for confusion was problematic.
       One sense in which it was used was in a technical sense within the
DNS. This sense is defined in RFC 7719 (which Andrew Sullivan was a co-
author of), and as the DNS and RDS are closely linked systems this
presents the potential for confusion. The definition is, however, of no
use to the RDS, as it is highly specific to the DNS.
       The second sense is in a more general data-theoretic use. This is
conceptually related to the DNS use, though there are significant
complications. This sense is the sense in which it was earlier used in
discussion of RDS requirements - the concept that within a data system
there is a source of the data that is considered to have precedence over
other sources of data. For example, in many data systems (including the
DNS) data may be cached, and that cached data is not considered
authoritative, even though it is a copy of authoritative data, and if that
non-authoritative data is ever found to be different to the authoritative
data, the authoritative data is assumed to be correct.
       The third sense is a legal sense, that is data that is guaranteed
to be correct by some authority. This sense of authoritative was found to
be confusing, and had been found to be problematic in the past, including
within ICANN. Michael Palage discussed examples where this had happened,
and made a strong case that if the term authoritative was to be used, it
would have needed to be appropriately qualified.
       With significant potential for confusion, it seemed as if avoiding
the specific term, but finding a term that captured the meaning of the
data-theoretic sense.A forms of words suggested included "Data from the
source repository,”. I felt that while that form of words looked
appropriate for our purposes, having untangled the definitional issues
that were the focus of the small group, it was appropriate to move
discussion back to the main group for further refining of terminology in
context.
        It should be noted that previous discussion involving the term in
Copenhagen did not intend to preclude the use of non-authoritative data
(caching and similar issues were regarded as implementation issues for
Phase 2, that should not be precluded by requirements in Phase 1).

       David
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170501/5b40f39e/attachment-0001.html>


More information about the gnso-rds-pdp-wg mailing list