[gtld-tech] "last update of RDAP database"

[Gustavo Lozano]

Brian,

The "last update of RDAP database" event action is analogous to the ">>>
Last update of WHOIS database:" field in the Whois output. You may find the
definition of this field in section 8 of
https://www.icann.org/resources/pages/registry-agreement-raa-rdds-2015-04-27
-en.

I am going to follow on this with you offline.

Regards,
Gustavo

From:  <gtld-tech-bounces at icann.org> on behalf of Brian Mountford via
gtld-tech <gtld-tech at icann.org>
Reply-To:  Brian Mountford <mountford at google.com>
Date:  Thursday, August 11, 2016 at 11:25
To:  "gtld-tech at icann.org" <gtld-tech at icann.org>
Subject:  [gtld-tech] "last update of RDAP database"

> ICANN RDAP tech folks,
> 
> I wanted to comment on an aspect of the ICANN operational profile. 1.4.12,
> 1.4.13 and 1.5.14 indicate that domains, nameservers and entities should
> include an event with type "last update of RDAP database". It sounds like you
> are assuming that the database will have a timestamp as of which all data are
> consistent, like a snapshot. Modern distributed databases don't necessarily
> have such a timestamp. If the database is "eventually consistent" (see
> https://en.wikipedia.org/wiki/Eventual_consistency), updates to a particular
> object may not show up in database reads until some time later. Technically,
> the only guarantee is that the new, updated value will show up eventually.
> 
> So when we return a "last update time", that doesn't mean that the data being
> returned in the RDAP response is as fresh as what was written on or before the
> last update time. The read may lag behind the update. I am going to go ahead
> and set the last update time to the current time, because that's when the most
> recent update could have occurred. But that will not mean that the returned
> data is current as of that time, because such a guarantee is impossible in an
> eventually consistent database.
> 
> Thanks.
> 
> Brian


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160819/93dcbe60/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4701 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160819/93dcbe60/smime.p7s>