[gnso-rds-pdp-wg] Suggestion re. RDS Accuracy Discussion

[Rod Rasmussen]

Shane,

Yep, this kind of meta-data would definitely be useful!  I also note with wry amusement that this group has again hit upon another concept we explored thoroughly in the EWG.  That concept is to provide a way for those who wish to provide a higher level of confidence that their data was accurate/reliable/trustworthy/(whatever word you want to describe it without starting a semantics war) could do so, and have the status of that reflected when it is published from the RDS - including a timestamp of the latest change.

Please see the following sections of the EWG final report for the relevant discussions:

V. b. c. (page 71)

V. c. b. (page 73)

Also see how we tied levels of validation to the SSAC 058 recommendations in V. f.

We also recommended that contact details could be listed as “inaccurate” yet remain in the system so a corrective action could be taken, yet those querying the system knew that the data was inaccurate. (Principle 94).  Principle 103 covers the timestamp suggestion.

There is a wealth of information available in this entire section V (Improving Data Quality) that is relevant to much of the discussion here, as once you start peeling the onion layers of these concepts, a lot of challenging issues arise and I cannot begin to describe the number of hours/days/weeks of discussions and efforts that went into crafting all the intricacies of the principles and description of necessary operational mechanics that came out in the final report. That said, I think this section represents some of the best work and thinking we put into this process as it covered both the blatant needs of today as well as making a system that addressed so many of the desirable features of a better way to accomplish the operations needed for managing such data in a modern system.  As I mentioned in a previous e-mail, separating the management of contact information from registration of individual domain names is a key foundation of this system, as it allows you to actually be able to implement the principles we’re talking about here.  You can still *manage* things from the perspective of a single domain in a UI for instance, but the underlying data is segregated.  Frankly, given the reality of domain portfolios and the roles that service providers provide across literally millions of domain names, I cannot see any practical way of accomplishing contact data “accuracy” by any definition without having this fundamental change in the way we handle “domain" data, separating the management of contact data from the rest of the information tied directly to the individual domain names that the contact information may be associated with via a contact role.

Cheers,

Rod

> On Oct 11, 2016, at 3:36 PM, Shane Kerr <shane at time-travellers.org> wrote:
> 
> Chuck,
> 
> [ Apologies I am way behind on this discussion, but your mail stuck
>  out. Hopefully I am not repeating an earlier topic. ]
> 
> At 2016-10-11 03:07:03 +0000
> "Gomes, Chuck" <cgomes at verisign.com> wrote:
> 
>> In my opinion as chair, I think the discussion about accuracy on our
>> list since our last meeting has been very good but I believe it will
>> become more relevant in our possible requirements deliberations
>> later.  When we get there, we will resume the discussion and we will
>> look at several key documents on accuracy.  For now and in particular
>> for our meeting tomorrow I ask everyone to direct their thinking to
>> how best to word the statement of purpose.  Is reasonable accuracy a
>> purpose of registration directory services?  Or is reasonable
>> accuracy a requirement of RDS?
> 
> Perhaps the focus should be on transparency here? That is, perhaps the
> actual requirement on our work is to provide a way that RDS users can
> know what expectations they can have?
> 
> For example, if I could know that the contact details for a domain
> operator has been updated in the past year, then there is a good chance
> that it is accurate. If it has not been updated in 7 years, then there
> is a good chance that it is less useful.
> 
> Even stronger forms of trust can be published, perhaps along the lines
> of the differences in X.509 certificates. So, having someone review
> government-issued identification, confirm company registrations, and
> make a phone call or two provides a certain amount of trustworthiness in
> the information. In a browser, you get a magic color. The equivalent
> can of course be done for RDS.
> 
> I do not think that we should propose any specific metrics, just
> support the idea of having and publishing metrics.
> 
> Such an approach not only has the benefit of improving the data for the
> user, but it also gives flexibility in directory requirements (possibly
> including ccTLD who want to use it but may have different requirements
> than gTLD). It also means that some other poor working group has to
> sort that mess out, leaving us to worry about happier topics. ;)
> 
> Cheers,
> 
> --
> Shane
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg