Dear all, We have the creation of NOC/role object as one of the action points for the RIPE NCC. However, after consulting numerous people we seemed to have agreed upon something where we don't have any specification for ;-(. Therefore, I am now doing a proposal for how the object could look like. Note that this proposal is a real draft due to my personal ignorance of your real needs in this area and the time that went by when we last discussed the contents of this object for the last time... Problem description: We see more and more person objects in the database that are apparently not persons but referrals to help desks or ISP NOCs. The problem with the usage of person objects for this matter is that the person object isn't really designed for this and that in certain cases we require certain objects to point to real persons for accountability reasons. Usage of non-persons in person objects undermines therefore the usability of the RIPE database. However, it is quite obvious that there is a need for such an object, especially for larger organizations. Proposal: Since the object will be derived from the 'person:' object I will only describe *all* the differences between the 'person:' object and the 'role:' object. Attributes that are not used: person: - for obvious reasons nic-hdl: - a NIC handle is by definition assigned to persons and not to organizations. Since we don't expect too many people using this object it seems reasonable that we don't use a number as a unique identifier. If we will need it in the future we can add it. Additional attributes: role: - the name of the object itself admin-c: - as in 'mntner' objects tech-c: - as in 'mntner' objects We could decide to leave the 'tech-c:' out, since what's the point in having a technical contact for a administrative object only anyway ? How to reference the 'role:' object from an object: Here we can opt for two different solutions: 1) We can allow people to use the 'role:' object in tech-c/zone-c attributes (not in admin-c, this one can only point to a human due to our current assignment criteria) 2) Use a special attribute. The attribute will be an optional, single line attribute for all objects that currently have an 'admin-c:/tech-c:/zone-c:' attribute defined (including the role/NOC object if desired. Note that this can cause undesired loops...): Example: preferred-contact: Please advise on better and shorter names, but that makes clear that it is intended that a customer first checks with NOC/role object people. How does the lookup work: The RIPE database can be configured for objects that have references to other objects in such a way that it will also show the referenced objects when querying an object with referenced other objects. Since the NOC object itself can have references to persons/roles, it seems best to do such a recursive lookup only one level deep whenever we find a NOC/person object referenced. Examples: $ whois 193/8 inetnum: 193.0.0.0 admin-c: DK13-RIPE tech-c: RIPE-NOC [...] person: David Kessens nic-hdl: DK13-RIPE [...] role: RIPE-NOC tech-c: DK58 [...] and $ whois RIPE-NOC role: RIPE-NOC tech-c: DK58 [...] person: Daniel Karrenberg nic-hdl: DK58 [...] We hope that this draft is useful enough for you all to let us define a sound proposal for the NOC/role object. Please make as many amendments/added features as you want and that you think is needed for the object, Kind regards, David Kessens RIPE NCC