RIPE NCC Request Tracking and Ticketing

Daniel Karrenberg

Document ID: ripe-183
Date: 1 March 1994

Contents

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 RIPE 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 that 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 Local Internet Registry has been assigned a Registry Identifier. This ID consists of the two-letter ISO 3166 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 RIPE NCC.

Where possible we suggest to include it in an RFC 822 header line of the messages concerned. The suggested format is: X-NCC-RegID: nn.example. Where it is impossible to modify the RFC 822 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 RIPE NCC staff will need to determine the registry 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. This ticket will be quoted by the RIPE 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 RIPE NCC.

The format of the ticket is the string "NCC#", followed by the last two digits of the year the ticket was issued, followed 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 hand 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 RIPE NCC, resource assignment or anything else.

Wherever possible we suggest to include tickets at the beginning of the RFC 822 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 the 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 the RIPE NCC staff will have to manually identify the ticket concerned and add it to the message. Messages received without reference to a ticket number may also cause a new ticket to be assigned and later merging to an existing ticket will cause delay.

4. Self Ticketing

For Local Internet Registries that keep their own tickets on requests the RIPE 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 with regard to 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 RIPE NCC if you would like to use self ticketing.