Suggestion: identify and thread trouble tickets

Colm MacCarthaigh colm at stdlib.net
Thu Jun 24 14:45:01 UTC 2004



Many network operators have Trouble Ticket systems (as per RFC1297)
which send mails notifying customers, peers and other interested parties
of network problems, events and so on. Many of these mails cross my
desk, so I thought it might be useful to make two small suggestions to
trivially increase the functionality of these mails ... use the mail
headers cleverly.

Firstly, a lot of us receive a lot of tickets and to ease the workload
we filter them into seperate mailboxes. To assist this process, rather
than making us all use unreliable filters based on a sender address or a
particular format to the subject, consider including a custom X-header,
here at HEAnet we use:

   X-HEAnet-TicketID: [ticket id]
   X-HEAnet-Ticket-Distribution: [public|noc|personal ..]

But only one is really neccessary (though I guess it depends on how easy
you want to make subfiltering), and it should be committed to.  No
matter what you do to your trouble ticketing system the X header should
remain. This would avoid the situation of breaking filtering on people
when you change whatever unique subtlety they happen to be relying upon.

Now secondly, after you've made it easy for people to distuingish your
tickets from those of others, consider making it easy for people to
distinguish your tickets from each other.

For 1 year now, HEAnet have been issueing tickets with Message-ID's
generated by our ticketing system, for example:

   To: noc at wherever
   From: Colm MacCarthaigh <colm.maccarthaigh at wherever>
   Subject: HEA-NOC/20040519-11 [OPEN] IPv6 packet loss on backbone        
   X-HEAnet-TicketID: 20040519-11
   X-HEAnet-Ticket-Distribution: public
   Message-ID: <20040519-11-1 at cyclops.heanet.ie>

And then subsequent updates to the ticket have headers such as:

   To: noc at wherever
   From: Colm MacCarthaigh <colm.maccarthaigh at wherever>
   Subject: HEA-NOC/20040519-11 [UPDATE] IPv6 packet loss on backbone        
   X-HEAnet-TicketID: 20040519-11
   X-HEAnet-Ticket-Distribution: public
   In-Reply-To: <20040519-11-1 at cyclops.heanet.ie>
   References: <20040519-11-1 at cyclops.heanet.ie>
   Message-ID: <20040519-11-2 at cyclops.heanet.ie>

I'm sure everyone can predict that the next mail would look like:

   To: noc at wherever
   From: Colm MacCarthaigh <colm.maccarthaigh at wherever>
   Subject: HEA-NOC/20040519-11 [UPDATE] IPv6 packet loss on backbone        
   X-HEAnet-TicketID: 20040519-11
   X-HEAnet-Ticket-Distribution: public
   In-Reply-To: <20040519-11-2 at cyclops.heanet.ie>
   References: <20040519-11-2 at cyclops.heanet.ie>
   Message-ID: <20040519-11-3 at cyclops.heanet.ie>

This simple feature has the effect of enabling mails concerning the same
ticket to be threaded/grouped (and whatever gmail is calling it these
days) in the users mail client, if their mail-client supports threaded
viewing. We all know what it looks like :). If a user wants to see them
chronologically instead, just turning the threaded viewing off is
enough. We've had no reports of problems and many people have found it
useful, and personally I find TT mails substantially more manageable in
this form.

If tickets are logged to a HTML archive, threaded mails can help there
also by allowing a nice way to see all ticket updates relevant to a
single issue.

I would imagine that all ticketing systems already have a unique number
per ticket (the ticket id) and incrementing a counter for each
update/close is not hard, so it's a simple enough feature to add (though
making sure the message ID's are in fact unique is critical). 

It's probably not a new idea, and it has almost certainly been implemented
before but none of the trouble tickets I get implement it. So, my humble 
suggestion is to consider adding it in the next rewrite of your ticketing 
system, or requesting it as a feature from your TT system vendor.

There may be problems we have not encountered in operation or I have not
considered, if so - comments welcome. 

-- 
Colm



More information about the NANOG mailing list