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

[Shane Kerr]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20161011/ea367577/attachment.sig>