Hi, I see that I have some "unfinished work" lying, and even though this won't close the action it should serve as a starting point for discussion and further guidance on direction. This concerns the desire to be able to reference a "role" in addition to a "person" in some of the RIPE DB attributes. Your comments are appreciated. - Håvard -*- Text -*- At the last RIPE meeting I volunteered to write something about referencing "roles" in the RIPE objects. Even though it is getting late I am now finally sitting down to write something to kick off some discussion on this topic. Today, what can be referenced from "admin-c", "tech-c" and "zone-c" in various objects is defined to only be persons. In some cases this proves to be impractical or requiring lots of updates when a person leaves his role to some other person. To give some motivation for some of this, consider the following examples: a) zone-c in domain objects. Quite often in my necks of the woods new subscribers to service providers contract with the service provider to set up and run a delegated zone in the DNS on behalf of the owner of the corresponding domain name. In that case it really is the service provider's DNS maintenance role (often referred to as "hostmaster") which performs this function, and the service provider would typically be referenced from a number of corresponding domain objects in the RIPE database (if you keep these objects there at all, ref. the relatively recent controversy over the domain objects). If the current rules (or common practice) are to be adhered to strictly, one is only allowed to reference persons even in tech-c and zone-c attributes. When persons move on to other roles, lots of objects have to be identified and updated. In the interest of reducing the number of objects requiring an update it would be convenient to be able to either point to a "role" or to a person. b) Role e-mail/phone/fax contact points Often, e-mail, phone or maybe even fax destined to the people manning the zone-c or tech-c roles should not be directed to their personal mailboxes/phones/faxes, but rather to common "role lists" or "role accounts", operational "common phone numbers" or maybe a specific fax number separate from the "normal fax". When only persons can be referenced via the zone-c and tech-c attributes, it becomes more difficult to correctly reflect this in the RIPE database. This should demonstrate why I think we need the ability to point to "roles" for some of the "contact person" attributes. How should this be implemented? I see several ways to do this: - Create a new object for the RIPE database called a "role" object, which can be referenced in addition to a "person" object. - Permit the "person" object to be used to register "roles" as well as real-world persons. Creating a separate "role" object would mean more work for the maintainers of the RIPE database software, and with the past resource shortfall at the RIPE NCC I do not really see this as an attractive alternative. It may be that the impact on the RIPE database software would be small, though, permitting this route. The second alternative of using the "person" object has its shortfalls as well, basically in that the syntax of the "role" has to fit in with what is permitted in a person name by the RIPE database software. Notably, there can be no "/" characters in a person name. Otherwise I see the person object as containing enough attributes, both mandatory and optional, that using the person object would be suitable for registering roles. Obviously, if we decide on using the "person" object, there needs to be developed some more detailed guidelines for it's use. So far for the "role" objects I have registered in this way I've always (?) added a "c/o Nnn Nnnnn/Nnnn Nnnnnnn" as the first line of the address, indicating some or all of the people manning the role. Note that I do not advocate permitting to refer to a "role" from an "admin-c" attribute. Also note that if we expand the usage of the "person" object as described above, there will be no way to enforce this automatically -- one would instead have to rely on doumentation and consensus for conventions of usage. I'm also not perfectly clear on which objects should permit referencing a "role" -- the need from the domain object seems obvious, for the "inetnum" it's maybe less obvious. Although this might not be what had been called for in my "assignment", I hope this note can lead to some discussion and hopefully a guidance for further directions at the upcoming meeting.