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

[Shane Kerr]

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 at 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 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  
> 
-------------- 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/0f9f6442/attachment.sig>