This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] The New "organisation object" Proposal
- Previous message (by thread): [db-wg] The New "organisation object" Proposal
- Next message (by thread): [db-wg] The New "organisation object" Proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ulrich Kiermayr
ulrich.kiermayr at univie.ac.at
Thu Sep 4 09:14:17 CEST 2003
Hi Engin, >>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 This makes a lot of sense as well. > 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... Hmm, if we waht to change the behaviour for consistency, we should do it now, when the irt is not to widely used. If we agree on this more generic solution, we could extend this behavior to other Objects that can be referenced as well. e.g. for mntner: itself. this would be a way tho prevent anyone from putting my mntner ont oan object. (This would solve the issue discussed in the context of the IRT Object - where the mntner of the object should be a proof of authenticity as well) other possible objects are persons, roles, key-certs, .... basically any object that can be referenced in an other object. But e.g. in person this could be optional as compared to irt where it is mandatory. also the ref-nfy: would be handy in all of these objects. The advantage would be to have a consistent behavior within all the referencing processes. Hope this makes sense. lG uk -- 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
- Previous message (by thread): [db-wg] The New "organisation object" Proposal
- Next message (by thread): [db-wg] The New "organisation object" Proposal
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]