[DBWG] Possible solutions to the changed attribute issue

[Nishal Goburdhan]

On 24 Aug 2020, at 11:05, Simon Seruyinda 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.


this is not my experience.  but i might be an anomaly.



> Besides validating that the email address the user provides is a valid 

> one,


to be clear, this validation does not occur;  you probably mean that 
there is check for something resembling email syntax.
that is not the same as a valid email address ..



> 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.


timestamping in UTC seem to be the rational thing to do..



> 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.


NO!

do you really mean to trade my pgp-signed updates, where *i* control my 
private key, for a system that sends out passwords in plain text, and 
fails basic best practices for web security [1]  despite being warned 
repeatedly?  i am all for securing access to the db;  please explain how 
removing my access to pgp-signed mail, promotes that notion?



> 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.


i can understand why it is easy to think that myafrinic2 will be a 
panacea.  but with no release date, or upcoming feature list, or [..]  
(i looked on both your website, and your portal, and could not see a 
release/feature schedule), i feel less comfortable about expecting 
anything from this project.  also - whilst your portal is likely fine 
for folks that want to click-through-to-make-irregular-changes, and i 
applaud efforts to make this as easy to use as possible for them, 
you’re forgetting:
# ben’s quite reasonable request for an API for larger networks that 
need the automation to scale
# “email” .. is just another API ..   (well, loosely ;-))



> 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.


i think most people don’t care what you call it;  the principles are 
simple:
# lock in maintainers for everything;  make these immutable (do *NOT* 
allow people to remove them (even intentionally) and if it means that 
you need to make the time during the Great StayHome of 2020 to schedule 
1-on-1 telephone calls with those, fewer than ten[2], users that removed 
their auto-generated maintainer, then *DO IT* for the sake of better 
security for all;
# generated the timestamp for changed / last-updated / 
call-it-what-you-want based on $transaction_time authenticated by 
$authorised_mnter;
# generated the “who changed it” (call it what you want) from the 
mnter.

at least this is how i read ben’s quite sensible suggestion earlier.
what, from the above, do you need this working group to help with?   
community consensus around mandatory maintainerS?  :-)



> 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/


i admit i didn’t think of the anti-spam thing;  so yeah, i have no 
issue hiding the email address in a regular query, as long as it can be 
retrieved via a  --history option (-B ?) or something similar.

-n.

[1]  https://observatory.mozilla.org/analyze/my.afrinic.net   that’s 
just one.  feel free to look through other similar tools.
[2]  https://lists.afrinic.net/pipermail/dbwg/2020-August/000216.html