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

[Ben Maddison]

Hi Michel,

On 08/05, Michel ODOU wrote:

> Hi Frank,

> 

> On 05/08/2020 13:22, Frank Habicht wrote:

> > 

> > my personal (non-chair) opinion is that this is dangerous.

> > Can we get consensus that this should not be allowed?

> > 

> > I believe all creations and updates of domain objects should enforce

> > that there is a mnt-by.

> 

> The mnt-by attribute is mandatory since June 2014. It is not possible to

> create/update a domain object without a mnt-by attribute. However, we

> still have many unprotected domain objects in the database that have not

> changed since.

> 

So, we need ideas for safely backfilling those old objects. Anyone?


> > 

> > From below I understand that there was no enforcement that later

> > creations/updates also had maintainers for these objects, correct?

> > 

> 

> There is no enforcement that later *updates* have a mnt-by attribute for

> person and role objects because, as explained in my previous mail, the

> mnt-by attribute remains optional on these objects, for historical

> reasons (you need a person or a role to create a maintainer because

> admin-c is mandatory - if at the same time you need a mntner to create

> the person/role object, then we have a cyclic dependency. a way to break

> it is to make the mnt-by optional in the person and role objects).

> 

I find it a little strange that anyone would choose to make mnt-by
optional, rather than admin-c. But that's not the issue.

Surely the solution is simply both be created, if necessary, in the same
transaction?
I know WHOIS is old and clunky, but that can't be all that hard?


> However, since September 2017, when a person or role object is *created*

> without a mnt-by attribute, the WHOIS will generate one for the user.

> This still applies.

> 

But yet, mnt-by can be subsequently removed, by accident?!

Cheers,

Ben
-------------- 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/20200805/6f7184c7/attachment-0001.sig>