Dear Carsten, My main concern here is security: If a person object is unprotected, you can change all information in it, except the name, currently. If we allow to change the name too, then the identity of the person object can totally be changed by anybody. This is probably not appropriate, since there are many unprotected person objects referenced from inetnums, aut-nums etc... On Mon, 29 Jan 2001, Carsten Schiefner wrote:

Colleagues,

[...]

What from time to time really annoys me is the fact that you cannot change a person's name (necessary due to misspellings etc.) that is already referenced because the person's name together with the NIC handle is the primary key. You cannot delete and re-enter it either because it's already referenced. The only way to go is to send an email to the human db processor ;-) 'ripe-dbm@ripe.net' to get the data changed manually. I consider this as not very efficient.

[...]

Where I haven't made up my mind yet is the question whether this always should apply or only in thoses cases when a person object is maintainer protected. There might be further cases I have not in mind at all at the moment - so...

I explained my concern above: even if we decide to allow the name modifications, AFAIK we must exclude unprotected person objects. Even the "protected" person objects whose "protecter" maintainers have "NONE" and "MAIL-FROM" authorisation schemes, possibly. Best regards, Engin Gunduz RIPE NCC Database Group

Any comments will be appreciated.

Best regards,

-C.

Dear Carsten, Carsten Schiefner wrote:

Colleagues,

as a follow-up of the short discussion we have had last week during RIPE 38 I'd like to continue this discussion in the appropriate forum, the db-wg mailing list.

What from time to time really annoys me is the fact that you cannot change a person's name (necessary due to misspellings etc.) that is already referenced because the person's name together with the NIC handle is the primary key. You cannot delete and re-enter it either because it's already referenced. The only way to go is to send an email to the human db processor ;-) 'ripe-dbm@ripe.net' to get the data changed manually. I consider this as not very efficient.

During the meeting we were told by Joao and/or Andrej that basically there is no further need to have person's name _AND_ NIC handle as the primary key, only the NIC handle would be enough. Anyhow, I wouldn't like to touch this pragma.

Yes, in the new software the internal primary key for person object is a nic handle. As a matter of fact, in the current version of the database person name and nic handle do not constitute the primary key either, because we cannot have different person names with the same nic handle. If fact, this restriction exists as another level of protection from hijacking person objects. In many cases the person name authenticates the person object. So please consider how often you need to ask the database administration, and the disadvantages of having this restriction removed.

What I would like to propose is a second "pseudo" attribute in addition to 'delete:' - having no documentation purpose but functionality: the "I really know what I am doing right at the moment" attribute ('irkwiadratm:' ;-). This second "pseudo" attribute overruns the above mentioned db pragma and forces a change in a person's name (so 'force:' migt be better...).

Where I haven't made up my mind yet is the question whether this always should apply or only in thoses cases when a person object is maintainer protected. There might be further cases I have not in mind at all at the moment - so...

If you decide to have this facility in place, I think it should be restricted to maintained objects only. Regards, Andrei Robachevsky DB Group Manager RIPE NCC