Stephanie, I think this is a bit tangential to the idea, but since I raised the suggestion I'll address it. Before I do, just to be clear my proposal is to make transparent whatever means are available for a user of RDS to know how much to trust they may want to put in the data. If the registrar requires updates to be done with 2-factor authentication that uses a mobile phone, then that would be awesome to know, for example. :) ---- As for the malfeasant actors... I guess a "malfeasant actor" is someone trying to do something bad, not a thespian trying to get into the role of a bird. In that case, think of it like this. There are two types of inaccurate data: 1. Data that was never accurate. 2. Data that became inaccurate over time. In the case of data that was never accurate, we have two types: 1.a. Data that was intentionally incorrect. 1.b. Data that was accidentally incorrect. Seeing a recent update can insure that the case #2 is less likely. Intuitively I think a recent update will tend to mean that case #1.b is also less likely, since whatever is responsible for keeping it up to date at least cares enough to update it. (This may not be true, we would need data to confirm or reject this hypothesis.) Which leads us with data that is intentionally added. I don't think this is likely to become *more* inaccurate over time, so a recent update probably doesn't mean anything one way or the other. Now, the thing that might change this is that if data recently updated was given more trust because of the recent update, then yet bad guys will update their data more frequently. Still, this it true of any measure of trust. If you use a real postal address as a sign of trust, then people will use a real postal address belonging to someone else. The same with phone numbers, e-mail addresses and so on. ---- No matter what bad guys do, if a record hasn't been changed since 1991 it is probably out of date. :) Cheers, -- Shane At 2016-10-11 09:29:24 -0400 Stephanie Perrin <stephanie.perrin@mail.utoronto.ca> wrote:

Please correct me if I am wrong, but is it not true that in the case of malfeasant actors, a recent update may not be a sign of greater accuracy?

Stephanie

On 2016-10-11 03:36, Shane Kerr 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@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

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@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@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg