[db-wg] The New "organisation object" Proposal

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 at univie.ac.at          Tel: (+43 1) 4277 / 14104
>                                                Fax: (+43 1) 4277 /  9140

-- 
Engin Gunduz
RIPE NCC Database Group