RIPE NCC Request Tracking and Ticketing


                         Daniel Karrenberg
                          Manager RIPE NCC

                       Document-ID: ripe-183







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 information 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 established 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.







ripe-183.txt
                               - 2 -


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

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 NCC staff will need to determine the regis-
try manually. The message will 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 messages 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, followed by a four di-
git 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 processing priority,
sequence of receipt at the NCC, resource assignment or anything
else.



ripe-183.txt
                               - 3 -



Wherever possible we suggest to include tickets at the beginning  of
the RFC822 Subject: header line of the messages concerned, e.g.:

Subject: NCC#941234 Address space Request for BigNet Ltd.

The RIPE NCC will use this embedding when assigning ticket numbers.
If this is not possible 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 concerned 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.  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 refer-
ence 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 ticketing.




















ripe-183.txt