Colleagues, Attached please find a proposal for adding the organisation object type to the RIPE Database. As always, discussion about the document can be done on this mailing list. There will be a brief presentation at the RIPE meeting next week about organisation objects. -- Shane Kerr RIPE NCC
5.1 Basic use ----------------------------------
When modifying an organisation object the update should pass authorisation checks specified by one of the mntners listed in "mnt-by:" attributes of the organisation object.
s/should/must/ It would not just be convenient, it is a requirement.
When adding an "org:" attribute to an object, the update of the object should pass the following authorisation checks:
- from one of the mntners of the referenced organisation object - from one of the mntner objects that protect the referencing object
Again, s/should/must/. Secondly, it should be made explicit whether there is supposed to be an "and" or an "or" between the two items in the list (I assume there's an "and"). (Incidently, basically the same comment can be made about e.g. the document defining the IRT object, and I would not be surprised if the same comment applies to other documents -- this section seems like an instantiated boilerplate...) I have another comment too, and I wonder if the extension of the semantics of the "mnt-by" attribute to also cover creating a reference to the organization object is wise. I think (I may be wrong) that up until now, the "mnt-by" attribute has had the clear cross-object-type semantics of only protecting updates to the object where that particular mnt-by attribute is located. I wonder if it would not be a good idea to separate out the authorization information about who can reference the org object from the authorization information for who can update the object itself? There is precedent for splitting out this authorization information, ref. the IRT object. Thirdly, would it be a good idea to include "country" as a separate attribute, and not just have it "assumed to be part of the free-text address attribute"? Regards, - Håvard
Shane, On Thu, Jan 23, 2003 at 12:42:49PM +0100, ext Shane Kerr wrote:
An organisation object in the RIPE Database --------------------------------------------
1. Motivation -----------
Currently the RIPE Database stores two main types of contact information: person and role objects.
These provide a way to contact people responsible for operations or usage of the resources whose data is presented in the RIPE Database (IP blocks, autonomous systems, and domain names).
However, none of these provide an easy way of mapping resources to a particular organisation. A user looking up data must first find an object containing information about a contact point at that organisation and then, assuming all of that organisation's objects refer to this contact information, perform an inverse query on the Database to obtain a list of objects referencing the specified person or role.
This level of indirection can be somewhat obscure and therefore a request for a more direct way of attaching an object to an organisation can be seen as a useful addition to the RIPE Database.
This document is a proposal for an organisation object in the RIPE Database and the corresponding needed database functionality.
I don't understand why we need yet another object that has very simular functionality as the role/person object. Why don't we fix the role object if there is a problem with the role object ?!? Or, why don't we retire the role object and replace it with an organization object. Adding yet another object, while keeping a deficient object seems not the best route to me. Let's first fix what we have or get rid of it before we start adding new objects. Having three different objects that all have very simular but not exactly the same functionality will only add to the confusion. Yes, you can keep adding objects for all kind of special needs, but there comes a point where it's impossible for regular humans to deal with the database because they don't understand the fine differences of all the different contact objects and special obscure attributes. David K. ---
Hi David,
I don't understand why we need yet another object that has very simular functionality as the role/person object.
Why don't we fix the role object if there is a problem with the role object ?!? Or, why don't we retire the role object and replace it with an organization object. Adding yet another object, while keeping a deficient object seems not the best route to me. Let's first fix what we have or get rid of it before we start adding new objects.
Having three different objects that all have very simular but not exactly the same functionality will only add to the confusion.
Yes, you can keep adding objects for all kind of special needs, but there comes a point where it's impossible for regular humans to deal with the database because they don't understand the fine differences of all the different contact objects and special obscure attributes.
David K. ---
I fully agree with your comment Martin ---------------------------- Martin VYSKOCIL Telekom Austria AG Broadband Networks & Services Tel.: +43 59059 1 43429 FAX: +43 59059 1 43492 mailto:mvyskocil@highway.telekom.at
Hello,
However, none of these provide an easy way of mapping resources to a particular organisation. A user looking up data must first find an object containing information about a contact point at that organisation and then, assuming all of that organisation's objects refer to this contact information, perform an inverse query on the Database to obtain a list of objects referencing the specified person or role.
what are the legitimate, operationally justified, reasons for compiling this kind of information? Who is going to decide what is an organisation and what is only part of another organisation? E.g. Universities have different kinds of relations to their institutes, which may or may not be part of the university and even if, it may be subtle to decide whether they are subsidiaries or not. The same holds for companies, where subsidiaries are often separate legal entities. So, unless the ORG object should help build a business (relations) directory, which I guess is not the goal, what is it good for? -Peter
participants (5)
-
David Kessens -
Havard Eidnes -
Peter Koch -
Shane Kerr -
Vyskocil Martin