[DBWG] Possible solutions to the changed attribute issue

[Daniel Shaw]

Whatever else you do our do not do, please please please do NOT do away with email updates. This is currently the ONLY way to automatically/programmatically interact with the db. (You still have no public API).

It's crucial to have means to do updates other than a portal, regardless if said portal is some form of myafrinic or something in the main web site. Neither are automatable.

Even when (if?) you (hopefully) enable public API access, email updates should also remain so as to not break any tools out there that rely on it. At least not for a long deprecation period trust is widely publicised...

Whatever solution may or may not be created to track/timestamp updates needs to be done within the db such that it's agnostic to upgrade method, does not necessarily deprecate existing methods, and does not lock into a specific portal, nor prevent future changes (like adding public API).

-- Daniel

-------- Original Message --------
On 24 Aug 2020, 11:05, Simon Seruyinda < simon at afrinic.net> wrote:
Dear DBWG
We have had discussions internally regarding the changed attribute and we acknowledge the challenges sorrounding its effectiveness and accuracy as a reliable source of who made the changes and when.
Current WHOIS behaviour does not force the addition of a changed attribute during an update if one already exists.
Besides validating that the email address the user provides is a valid one, the changed attribute is for the users own reference. Nothing can be determined by a third party by looking at the email address provided here.
As pointed out by Frank, currently the date is not validated to confirm that it matches the date when update is being done, but we can change this to make it auto-generated.
In our internal discussions, the following options were considered:
1. Eliminate other avenues of creating and updating WHOIS objects such as webupdate and auto-dbm and leave only myafrinic. Allow non-registered contacts to register on the portal with limited access to specific functionality so that when a change or creation of an object is done, we know exactly who is making the updates. This would enable us to auto-generate the changed attribute. This would be possible in myafrinic v2 which is currently under development.
2. Slowly deprecate the changed attribute and replace it with two auto-generated attributes namely created and last-updated or last-modified both of which would take the date whose format we can discuss and agree upon here.
How have other RIRs handled this?
RIPE:
Began deprecation of the changed attribute in 2015, and replaced it with created and last-modified attributes.
https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-ripe-database
APNIC:
Replaced the changed attribute with the last-modified attribute
https://www.apnic.net/get-ip/faqs/last-modified-attribute/
Your comments and suggestion on the best implementation approach to take are welcome.
Regards;
Simon
_______________________________________________
DBWG mailing list
DBWG at afrinic.net
https://lists.afrinic.net/mailman/listinfo/dbwg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/dbwg/attachments/20200827/7877d3ad/attachment.html>