David, Thanks for starting the discussion on this. I have some input to this, see below. Unfortunately I won't be able to come to the RIPE WG-sessions, but Steven Bakker will be there. At 5:17 pm 26/1/1996, David.Kessens@ripe.net wrote:
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 ?
I think we should not distinguish. A "person:" attribute would do, I think (however you call it, eg tech-c; the point is: *one* such object). Besides, this is mainly for NOCs and such (at least this is what we would use it for), so it would be technical people on it anyway only. But I think we need more attributes. Basically the role object needs to reflect what you need to know about something like a NOC: Who's in it (as you say), how to contact (might be derived from the other attributes), but also: What are the out-of-hours procedures. There are several possible ways to include that. I would propose something like: role: [mandatory] [single] address: [mandatory] [multiple] (as in person) phone: [mandatory] [multiple] ( " ) fax-no: [optional] [multiple] ( " ) e-mail: [optional] [multiple] ( " ) trouble: [optional] [multiple] (this is needed for trouble contact) (see below) person: [mandatory] [multiple] (this should be handles, obviously) (I see you used tech-c for this purpose, that is basically the same) remarks: [optional] [multiple] (as in person) notify: [optional] [multiple] ( " ) mnt-by: [optional] [multiple] ( " ) changed: [mandatory] [multiple] ( " ) source: [mandatory] [single] ( " ) What was actually the difference between notify and mnt-by? Do we need both? If feel quite strongly that we need something where you can specify the procedure to get in touch with the "role". This could be for example: trouble: Working days 0900-1700 CET: phone: xxx trouble: Working days 0900-1700 CET: e-mail: xxx trouble: Working days 0900-1700 CET: fax: xxx trouble: other times: phone: xxx trouble: other times: pager: xxx trouble: other times: mobile phone: xxx trouble: if all fails: phone: xxx trouble: NOTE: Please always try the phone before paging us! ... and so on. I don't think it is adviseable to be too precise in the specification, as there are certainly folks out there who want to put in notes like above. Thus one attribute like this "trouble" with free content would do. The reason why I think we still need such an attribute: We would like to be able to automatically derive contact procedures from the RIPE DB, to use it as a list. Of course we can also put it in the remarks, but I think one of the reasons for this object is to have this sort of attribute.
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.
I strongly feel that we should go away from specifying individuals in the other objects such as "route" or "as-num". But obviously not everybody will do that. Therefore I would suggest to use the tech-c: attribute for that. It makes perfect sense to say "tech-c: DFN-NOC" for example. Admin can stay, I don't have a strong view on that. The special attribute you propose in 2) makes it only more complicated, and it doesn't actually give us anything, does it? Hopefully people will not do something like specifying persons *and* a role as tech-c's in one object, but it shouldn't create problems either, you only might get a person twice as output.
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 [...]
Agree. Looks fine. Basically with the role object the goal is to get away from individuals, so the one-level limited recursion makes perfect sense, imo.
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
What do others think? Michael