RIPE NCC Request Tracking and Ticketing

Deear Colleagues,

We hav now reached the point where we have to streamline request
processing at the NCC even further. This necessitates the introducion
of tickets. I have written up a proposal on how to do things from
our point of view which tries to explain *why* we need certain things. 
I would apreciate feedback from you about this as early as possible. 

If you have any questions, please do not hesitate to contact me.

Regards

Daniel Karrenberg
RIPE NCC Manager






          RIPE NCC Request Tracking and Ticketing

                        A Proposal


                     Daniel Karrenberg
                      Manager RIPE NCC

                     February 15th 1995





1.  Introduction

The RIPE NCC is  now  processing  a  substantial  amount  of
requests from local registries as well as individuals.  Many
of these requests require  multiple  interactions  with  the
customer (requester) before they can be completed.

In addition the NCC has to process requests  with  different
levels of service since February 1st 1995.

This situation  makes  it  necessary  to  formalise  request
tracking  and  introduce a ticketing system to keep track of
requests.  This will improve the speed of processing as well
as  reduce  the resources necessary to establish the context
when processing requests.  It is hoped it will also  improve
service to the customer by giving quick and automated infor-
mation about the status of a particular request.



2.  Registry Identification

Each European Local Internet Registry has  been  assigned  a
registry  Identifier.  This  ID  consists  of the two letter
ISO3166 country code of the country the  registry  is  esta-
blished  in  followed  by  a  dot  and  a  unique, hopefully
descriptive, name for the registry.   Registry  IDs  can  be
found  in  ftp://ftp.ripe.net/ripe/registries/, in fact they
are identical to the file names in this directory.

In order to make an unambiguous link back to the  requesting
registry  and  to  establish the priority of a request it is
necessary that the registry ID is  quoted  on  all  messages
dealing with requests to the NCC.

Where possible we suggest to include it in an RFC822  header
line of the messages concerned. The suggested format is:
                           - 2 -


X-NCC-RegID: nn.example

Where it is impossible to modify  the  RFC822  header,  this
line can also be included in the body of the message.

Failure to include the registry ID in messages dealing  with
requests  may delay processing as the message may be treated
on a "time-permitting" basis if a registry cannot readily be
identified.



3.  Ticketing

The RIPE NCC will assign a unique ticket to each request  as
it  is first received at the NCC. This ticket will be quoted
by the NCC on each message to the customer dealing with  the
request.   It  should also be quoted by the customer in mes-
sages about this request sent to the NCC.

The format of the ticket is he string  "NCC#",  followed  by
the  last two digits of the year the ticket was issued, fol-
lowed by a four digit ticket number, e.g.

                         NCC#944711


Tickets should be quoted exactly like this. The letters  NCC
and the hash sign form an integral part of the ticket.

The ticket format is designed with the following criteria in
mind:


 +   It has to be syntactically detectable when imbedded  in
     text  such  as  "In reference to tickets NCC#941234 and
     NCC#946789 we would like to ...".


 +   It has to be easily quotable out of band like "Hey, can
     you  hand  me  the  file  about NCC (ninetyfour) twelve
     thirtyfour please.".


 +   It has to be representable in basic E-Mail and in other
     means of written communication.


Tickets are simply identifiers for a  specific  request  and
have  no  semantic  meaning of their own with regard to pro-
cessing priority, sequence of receipt at the  NCC,  resource
assignment or anything else.

Where possible we suggest to include tickets  in  an  RFC822
                           - 3 -


header  line of the messages concerned. The suggested format
is:

X-NCC-Ticket: NCC#941234

Where it is impossible to modify  the  RFC822  header,  this
line  can  also  be included in the body of the message.  If
desired the ticket number can also be included in text  near
the top of the body of the message.

Failure to include the ticket number in messages  concerning
ongoing  requests will cause additional delays in processing
as NCC staff will have to manually identify the ticket  con-
cerned  and add it to the message. Messages received without
reference to a ticket may also cause  a  new  ticket  to  be
assigned  and later merging to an existing ticket will cause
delay.


4.  Alternative Embeddings

Where it is too cumbersome to include two separate lines for
the registry ID and the ticket in a message, the information
can be combined on a single line like this:

X-NCC-Request: nn.example NCC#941234



5.  Self Ticketing

For registries who keep their own tickets  on  requests  the
NCC  is  willing  to  consider  to  allow  self ticketing of
requests. We would suggest to use a format consisting of the
registry ID, a hash sign and a number, e.g.


                     nn.example#123456


but we are flexible w.r.t. the ticket format as long  as  it
is unique and satisfies the criteria mentioned above.

If the need arises we will also investigate methods to cross
reference  ticket numbers of different systems as necessary.
This may mean that we will have to  carry  multiple  tickets
for  each  request.   The  above  suggestion  is intended to
minimise the need for that.

Please contact the NCC if you would like to use self ticket-
ing.