[DBWG] Possible solutions to the changed attribute issue

Nishal Goburdhan nishal at controlfreak.co.za
Mon Aug 24 15:29:49 UTC 2020


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



More information about the DBWG mailing list