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