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.
