draft NOC/role object proposal

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 at 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