[DBWG] DBWG-2: proposal to auto-generate contents of the mandatory "changed" field in db objects.

Ben Maddison benm at workonline.africa
Sun Aug 2 04:23:14 UTC 2020

On 07/31, Nishal Goburdhan wrote:

> On 29 Jul 2020, at 22:28, Ben Maddison via DBWG wrote:


> > Hi all,

> >

> > I think that the principle is sensible, but the details might be tricky.

> >

> > The "date" part is easy to calculate on receipt.

> > The "from" part is less so:

> > - updates via the web-submission thingy

> > - updates via the REST-wotsit

> > - updates generated by tooling that sets the 'changed:' to the correct

> > user but generates the 'From:' using a shared/dummy mailbox

> >

> > Having accurate 'changed:' is important for attribution, as the current

> > legacy space saga reminds us.



> nishal at slartibartfast:~$ date && whois -B -h whois.afrinic.net ndg-afrinic |

> grep -A1 changed

> Fri Jul 31 18:08:21 SAST 2020

> changed: ben.maddison at domain.invalid 19990730

> source: AFRINIC


> are you saying the database is incorrect? :-)


Wow, it doesn't even check the date? Yuk!


> > If we're going to solve this properly, perhaps referencing the mntner

> > used to authorise the update is the way to go? (it's transport

> > independent, less spoof-able, and maybe more useful for a later audit).

> > Users could then provide an optional 'changed-reason:', providing email

> > attribution and/or commit-msg things.


> i support ben’s very common-sense suggestion.


So, 'changed:' is specified in RFC2622 section 3.1. It doesn't leave
much (any) room for alternative syntax.

I am personally not much interested in spending cycles on fixing RPSL
specs (and this wouldn't even be top of the list if I were).

Given that this field must contain "<rfc822 address> <yyyymmdd>", anyone
have any clever ideas how to auto-populate it in a non-useless way?

Perhaps recursively looking up an address via the authenticating mntner
in one of the two ways:

mntner > upd-to
mntner > tech-c > e-mail

Those both really only on the presence of mandatory attributes.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/dbwg/attachments/20200802/ad89a4dc/attachment.sig>

More information about the DBWG mailing list