Hi Ulrich, On 2003-09-03 16:12:49 +0200, Ulrich Kiermayr wrote:
Hello,
"org:"
[ .... ] UNSPECIFIED" values. It is optional in all other objects, and it is single valued in all objects.
This Restriction may be reasonable for 'ressources' but for persons/roles beeing single does not make sense to me, because a person can belong to more than one organisations. if it was single I'd have to duplicate the object just to reflect that.
I think it makes sense to make it multiple-valued in person/roles, and perhaps in some object types. We need to think a little more.
4. Authorisation checks ----------------------------------
When modifying an organisation object the update must pass authorisation checks specified by one of the mntners listed in the "mnt-by:" attributes of the organisation object.
When adding an "org:" attribute to an object, the update of the object should pass the following authorisation checks:
- from one of the maintainers of the organisation object
Ihis might be problematic as well, because. There are situations where an organisation is not maintaining it's own org-object (e.g. LIR-Organisations). So if I want to reference the object in the new staff-member's person object, i'd have to go to whoever maintains the org-object. In that case the Ripe-NCC (could not chech wether this person really belongs to my organisation)[1], therefore they would just say yes (or no?)
so the idea would be to seperate the reference authorisation from the object-maintainer. Like in the irt-object one could introduce an 'auth:' attribute to check the tagging.
OK, that makes sense too. How about introducing "mnt-ref:" attribute for this purpose? That is, "mnt-by:" will protect/control the organisation object itself. And, "mnt-ref:" will control the references to this organisation object. Thus, an LIR org object might be: organisation: ORG-AA11-RIPE [...] org-type: LIR mnt-by: RIPE-NCC-HM-MNT mnt-ref: LIR-MNT mnt-ref: RIPE-NCC-HM-MNT Here, we have "mnt-ref: RIPE-NCC-HM-MNT" because RIPE NCC hostmaster will need to add references to this organisation object when creating/modifying allocation inetnums and aut-nums. The problem with introducing 'auth:' attribute would be that, this (multiple-valued) attribute would need to contain the RIPE NCC hostmaster's PGP key as well (or whatever auth method is used), as explained above, but when RIPE NCC hostmaster changes the PGP key, all LIR org objects would need to be modified accordingly, which is not practical. Hence we would propose "mnt-ref:". To maintain consistency, perhaps we could do the same in irt objects: Change the "auth:" attr into "mnt-ref:" and have mntner names in it (rather than auth methods directly). Also, "irt-nfy:" might be changed into "ref-nfy:", again for consistency. But perhaps this is out of scope... Thanks for great feedback. -engin
Apart from that it sounds confusing to me to introduce different behavouurs for simmilar things (reference irt: compared to reference org:)
- from one of the maintainers of the object being updated
btw. speaking of irt-objects: might we want to think about adding the mnt-irt: to the organisation as well (reflecting a different constituency model: being responsible for an organisation as compared to being responsible for a ressource).
i hope this makes sense lG uk
[1] Or do we want the NCC to perform these checks?! -- Ulrich Kiermayr Zentraler Informatikdienst der Universitaet Wien Network/Security Universitaetsstrasse 7, 1010 Wien, Austria
eMail: ulrich.kiermayr@univie.ac.at Tel: (+43 1) 4277 / 14104 Fax: (+43 1) 4277 / 9140
-- Engin Gunduz RIPE NCC Database Group