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.