RFC 6137
The Network Trouble Ticket Data Model (NTTDM)
RFC 6137: The Network Trouble Ticket Data Model (NTTDM) 🎀
Bestie, this one is an Experimental RFC from the Independent Submission stream, so it's a community experiment and not an official Internet Standard. 🧪✨ Here's the title-block tea:
- Title: The Network Trouble Ticket Data Model (NTTDM)
- RFC number: 6137
- Stream: Independent Submission
- Category: Experimental
- Date: February 2011
- ISSN: 2070-1721
- Editors: D. Zisiadis, S. Kopsidas, M. Tsavli, and G. Cessieux (each listed as Ed.), with affiliations shown as CERTH and CNRS
- Obsoletes / Updates: Nothing. It doesn't obsolete or update any other RFC. 💅
Abstract ✨
Okay so picture this: a bunch of different networks are all connected together, like a Grid, and each one has its own trouble tickets (TTs) coming in from its own inter-connected environment. 🌸 Managing that is a whole mess for the institutions involved, because every participant handles trouble in its own way, depending on its local technical and linguistic profile. Their TT systems also collect, represent, and share ticket info in different formats. Iconic chaos, honestly. 💀
That makes the daily workload for a central Network Operation Centre (NOC) a challenge all on its own. The fix is normalization: converting every TT into one common format at the central NOC, which makes it way easier to present, store, and handle the tickets. 🦋 This document provides a model for automating the collection and normalization of TTs received by the multiple networks that form the Grid. Each participant keeps using its home TT system inside its own domain, while the central NOC gathers everything into the normalized format for storage and handling. XML is the common representation language here. 🧚 The model was defined and used as part of the networking support activity of the EGEE (Enabling Grids for E-sciencE) project.
Status of This Memo 🌈
Okay, status check: this document is not an Internet Standards Track specification. 🙈 It's published for examination, experimental implementation, and evaluation.
It defines an Experimental Protocol for the Internet community. It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion, and they make no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard. Iykyk, see Section 2 of RFC 5741. 🫶
Info about the current status of this document, any errata, and how to give feedback can be found at http://www.rfc-editor.org/info/rfc6137. 💜
Copyright Notice 🎀
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 💖
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, bestie, because they describe your rights and restrictions with respect to this document. 📜
Table of Contents 🗂️
1. Introduction ....................................................4
1.1. Terminology ................................................5
1.2. Notations ..................................................6
1.3. About the Network Trouble Ticket Data Model ................6
1.4. About the Network Trouble Ticket Implementation ............7
1.5. Future Plans ...............................................7
2. NTTDM Types and Definitions .....................................7
2.1. Types and Definitions for the TYPE Attribute ...............8
2.1.1. Defined .............................................8
2.1.2. Free ................................................8
2.1.3. Multiple ............................................8
2.1.4. List ................................................8
2.2. Types and Definitions for the VALID FORMAT Attributes ......9
2.2.1. Predefined String ...................................9
2.2.1.1. Definitions of the Predefined Values ......10
2.2.2. String .............................................13
2.2.3. Datetime ...........................................13
3. NTTDM ..........................................................14
3.1. NTTDM Components ..........................................14
3.1.1. NTTDM Attributes ...................................14
3.2. NTTDM Aggregate Classes ...................................15
3.2.1. NTTDM-Document Class ...............................15
3.2.2. Ticket Class .......................................15
3.2.3. Ticket Origin Information ..........................17
3.2.3.1. PARTNER_ID ................................17
3.2.3.2. ORIGINAL_ID ...............................17
3.2.4. Ticket Information .................................17
3.2.4.1. TT_ID .....................................17
3.2.4.2. TT_TITLE ..................................18
3.2.4.3. TT_TYPE ...................................18
3.2.4.4. TT_PRIORITY ...............................18
3.2.4.5. TT_STATUS .................................19
3.2.4.6. TT_SOURCE .................................19
3.2.4.7. TT_OPEN_DATETIME ..........................19
3.2.4.8. TT_CLOSE_DATETIME .........................20
3.2.5. Trouble Details ....................................20
3.2.5.1. TT_SHORT_DESCRIPTION ......................20
3.2.5.2. TT_LONG_DESCRIPTION .......................20
3.2.5.3. TYPE ......................................21
3.2.5.4. TT_IMPACT_ASSESSMENT ......................21
3.2.5.5. START_DATETIME ............................21
3.2.5.6. DETECT_DATETIME ...........................22
3.2.5.7. REPORT_DATETIME ...........................22
3.2.5.8. END_DATETIME ..............................22
3.2.5.9. TT_LAST_UPDATE_TIME .......................23
3.2.5.10. TIME_WINDOW_START ........................23
3.2.5.11. TIME_WINDOW_END ..........................23
3.2.5.12. WORK_PLAN_START_DATETIME .................24
3.2.5.13. WORK_PLAN_END_DATETIME ...................24
3.2.6. Related Data .......................................24
3.2.6.1. RELATED_EXTERNAL_TICKETS ..................24
3.2.6.2. ADDITIONAL_DATA ...........................25
3.2.6.3. RELATED_ACTIVITY ..........................25
3.2.6.4. HISTORY ...................................25
3.2.7. Localization and Impact ............................26
3.2.7.1. AFFECTED_COMMUNITY ........................26
3.2.7.2. AFFECTED_SERVICE ..........................26
3.2.7.3. LOCATION ..................................26
3.2.7.4. NETWORK_NODE ..............................27
3.2.7.5. NETWORK_LINK_CIRCUIT ......................27
3.2.7.6. END_LINE_LOCATION_A .......................27
3.2.7.7. END_LINE_LOCATION_B .......................28
3.2.8. Contact Information ................................28
3.2.8.1. OPEN_ENGINEER .............................28
3.2.8.2. CONTACT_ENGINEERS .........................28
3.2.8.3. CLOSE_ENGINEER ............................29
3.2.9. Security ...........................................29
3.2.9.1. HASH ......................................29
3.3. NTTDM Representation ......................................29
4. Internationalization Issues ....................................31
5. Example ........................................................31
5.1. Link Failure ..............................................31
6. Sample Implementation: XML Schema ..............................32
7. Security Considerations ........................................43
8. IANA Considerations ............................................44
9. Contributors ...................................................44
10. Acknowledgements ..............................................45
11. References ....................................................45
11.1. Normative References .....................................45
11.2. Informative References ...................................451. Introduction 🦋
Okay, so the big picture: problem-impact assessment, reporting, identification, and handling, plus spreading trouble info around and delegating authority, are the main jobs the members of a Grid have to get done. 👑 They need to do all of that to manage the network well and keep their services running smoothly for their users. No pressure. 🙈
Each network domain uses its own TT system, and each one delivers tickets in a different format. Meanwhile the TT load keeps growing right alongside the size of the network and the number of users it serves. 📈
So we define a data model for TT normalization, the Network Trouble Ticket Data Model (NTTDM), which is initially aimed at the network providers serving EGEE [8]. The model is designed in accordance with RFC 1297 [11] and meets the requirements of the multiple TT systems in use. 💅
The NTTDM:
- is both effective and comprehensive, because it supports the core activities of the Network Operation Centres (NOCs). It's also dynamic, so extra options can be added in the future as demand grows. 🌟
- provides an XML representation for sharing incident information across administrative domains, between parties that have operational responsibility for remediation or a "watch-and-warn" policy over a defined constituency. 🫶
- encodes information about hosts, networks, and the services running on those systems, attack methodology and associated forensic evidence, the impact of the activity, and limited approaches for documenting workflow. 🔍
- aims to simplify TT exchange within the boundaries of a Grid and to boost the functional cooperation of every NOC and of the Grid Operation Centre (GOC). Community adoption of the NTTDM enhances trouble resolution within the Grid framework and gives everyone network status awareness by modeling collaboration and information exchange among operators. 🤝
- provides a common format that lets GOCs and all participating NOCs store, exchange, manage, and analyze TTs (assessment of TT impact). 📊
- provides increased automation in handling a TT, since the network operators all share a common view of the incident. ⚡
The model was designed and used as part of the networking support activity of the EGEE project. One of the subtasks of that support activity was to enhance the ENOC (EGEE Network Operation Centre) [9] procedures for better overall network coordination of the Grid. 🌈
1.1. Terminology
Okay, first up, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [1]. 🎀
The NTTDM uses specific keywords to describe its different data components. They are: Defined, Free, Multiple, List, Predefined String, String, Datetime, Solved, Cancelled, Inactive, Superseded, Opened/Closed, Operational, Informational, Administrative, and Test. ✨
These keywords, as used in this document, are to be interpreted as described in Section 2. 💅
Acronyms bestie, you'll want these handy 🧚:
- TT: Trouble Ticket
- NTTDM: Network Trouble Ticket Data Model
- DB: Database
- EGEE: Enabling Grid for E-sciencE
- ENOC: EGEE NOC
- NOC: Network Operation Centre
- GOC: Grid Operation Centre
- NREN: National Research and Educational Network
- QoS: Quality of Service
- UML: Unified Modeling Language
- XML: Extensible Markup Language
1.2. Notations
So the NTTDM is specified in two ways: as an abstract data model and as an XML Schema. 🦋 Section 3 gives you a Unified Modeling Language (UML) [10] model that shows the individual classes and how they relate to each other. The semantics of each class are discussed and their attributes are explained. In Section 6, that UML model gets converted into an XML Schema [2] [3] [4] [5]. A specific namespace [6] is defined too. 🌸
Quick vocab check: "XML document" means any instance of an XML Document. "NTTDM document" refers to specific elements and attributes of the NTTDM Schema. And "class" and "element" are used interchangeably to mean either a UML class in the data model or its matching Schema implementation. Lowkey important to get these straight 🙈
1.3. About the Network Trouble Ticket Data Model
The NTTDM is a data representation that gives you a framework for normalizing and sharing information among network operators and the GOC about troubles within the Grid boundaries. 💜 A lot of thought went into the design, and here's the tea:
- The data model serves as a common storage and exchange format. 📦
- Every NOC still uses its home TT system for network management within its area of control. 🏠
- There's no universally adopted definition of a trouble, so in the NTTDM definition, the term is used with a comprehensive meaning that covers all NOCs. 🌈
- Handling every possible definition of a trouble incident would call for an extremely expanded and complex data model. So the NTTDM's purpose is to serve as the basis for normalizing and exchanging TTs. It's flexible and expressive so that specific NOC requirements are met. Specific NOC information is kept outside the NTTDM, and external databases can be used to feed it. 🧠
- The domain of managing this information isn't fully standardized and has to rely on free-form textual descriptions. The NTTDM tries to strike a balance between supporting this free-form content and still allowing automated processing of incident information. ⚖️
The NTTDM is only one of several feasible TT data representations. The goal of this design was to be as effective and comprehensive as these other representations, and to account for managing a general Grid environment. The TT formats already in use influenced the design of the NTTDM. 👑
1.4. About the Network Trouble Ticket Implementation
Here's an example of a typical use case, so you can see it in action 🍓
The Grid project EGEE manages its infrastructure as a network overlay over the European National Research and Educational Networks (NRENs), and it wants to be able to warn EGEE sites when the network is unavailable. ⚠️ Thanks to collaboration with its network provider, the EGEE NOC receives a high volume of TTs (800 tickets/month, 2500 emails/month) from 20 NRENs and should always be able to cope with a load that heavy. 😭 Thanks to the NTTDM, the EGEE NOC can automate the TT workflow:
- The TT is filtered, sorted, and stored in a local database (DB). 🗂️
- The TT's impact on the Grid is assessed. 🔍
- The TT is pushed to an ENOC dashboard application and other tools (EGEE TT system, statistics, etc.). 🚀
1.5. Future Plans
Since this is an Experimental document, operational experience will be used to expand the subsections of Section 3.2.3, "Ticket Origin Information", below. 🔬 The current specification is already in use within EGEE. Other Grids are free to use it and report comments to the authors. After enough experimentation, the authors would like to advance it to the Standards Track. 🌟
2. NTTDM Types and Definitions ✨
Each data element in the TT data model has a type, and this section talks about those data types. Where possible, native Schema data types were adopted. For the more complicated formats, regular expressions or external standards were used. 🧩
2.1. Types and Definitions for the TYPE Attribute
These types are used to describe the TYPE attribute. 🎀
2.1.1. Defined
The Defined data type means the data model gives you a way to compute this value from the rest of the fields. 🧮
The Defined data type is implemented as "Defined" in the Schema. 💖
2.1.2. Free
The Free data type means the value can be freely chosen. 🌷
All Free strings SHOULD have the language used as an attribute. 🗣️
The Free data type is implemented as "Free" in the Schema. 💖
2.1.3. Multiple
The Multiple data type is one value picked from multiple fixed values. 🎯
The Multiple data type is implemented as "Multiple" in the Schema. 💖
2.1.4. List
"List" means many values picked from multiple fixed values. 📝 The List data type is implemented as "List" in the Schema. 💖
2.2. Types and Definitions for the VALID FORMAT Attributes
2.2.1. Predefined String
A Predefined String means the different values are predefined in the data model. 📚
Each field that requires a Predefined String contains a specific value. Figure 1 shows the allowed values for those fields. 👀
+------------------------+-----------------------------------+
| FIELD NAME | VALUES |
+------------------------+-----------------------------------+
| TT_TYPE | Operational, Informational, |
| | Administrative, Test |
+------------------------+-----------------------------------+
| TYPE | Scheduled, Unscheduled |
+------------------------+-----------------------------------+
| TT_PRIORITY | Low, Medium, High |
+------------------------+-----------------------------------+
| TT_SHORT_DESCRIPTION | Core Line Fault, Access Line |
| | Fault, Degraded Service, Router |
| | Hardware Fault, Router Software |
| | Fault, Routing Problem, Undefined |
| | Problem, Network Congestion, |
| | Client Upgrade, IPv6, QoS, VoIP, |
| | Other |
+------------------------+-----------------------------------+
| TT_IMPACT_ASSESSMENT | No impact, Reduced redundancy, |
| | Minor performance impact, Severe |
| | performance impact, |
| | No connectivity, On backup, |
| | At risk, Unknown |
+------------------------+-----------------------------------+
| TT_STATUS | Opened, Updated, Closed, Solved, |
| | Inactive, Cancelled, Reopened, |
| | Superseded, Opened/Closed |
+------------------------+-----------------------------------+
| TT_SOURCE | Users, Monitoring, Other NOC |
+------------------------+-----------------------------------+
Figure 1. Allowed Predefined String ValuesThe Predefined String data type is implemented as "xs:string" in the Schema, with a sequence of enumerations for the allowed values. 🌈
2.2.1.1. Definitions of the Predefined Values ✨
okay so this is where the actual value lists live, bestie 🎀 every single predefined value, no skipping 💅
TT_TYPE
Operational: for network incident and maintenance only.Informational: information about the TT system or the exchange interface (maintenance, upgrade).Administrative: information about the access to the TT system (credentials) or the exchange interface.Test: to test the TT system or the exchange interface, etc.
TYPE
Scheduled: the incident was scheduled to happen.Unscheduled: the incident was unscheduled.
TT_PRIORITY
Low: the TT priority is low.Medium: the TT priority is medium.High: the TT priority is high.
TT_SHORT_DESCRIPTION
Core Line Fault: malfunction of a high-bandwidth core line.Access Line Fault: malfunction of a medium-bandwidth access line.Degraded Service.Router Hardware Fault: malfunction of the router hardware.Router Software Fault: malfunction of the router software.Routing Problem: incident regarding the routing service.Undefined Problem: nature of the problem not identified.Network Congestion: problem due to traffic at the network (blocked).Client Upgrade: incidents regarding client/services upgrade.IPv6: incident regarding the IPv6 network.QoS: incident regarding the Quality of Service (QoS) of the network.VoIP: incident regarding Voice over IP (VoIP).Other: non-listed incident.
TT_IMPACT_ASSESSMENT
No impact: the incident does not cause any impacts.Reduced redundancy: the incident reduces network redundancy.Minor performance impact: the incident causes a minor performance impact.Severe performance impact: the incident causes a severe performance impact.No connectivity: the incident causes connectivity failure.On backup: the incident causes a malfunction of backup services.At risk: the incident should not have any impact but could possibly cause some trouble.Unknown: the nature of the impact is not identified.
TT_STATUS
Opened: the ticket is opened.Closed: the ticket is closed.Updated: the ticket's contents have been updated.Cancelled: the ticket has been opened twice; one of the tickets is cancelled, and a relationship between them is defined via theRELATED_ACTIVITYfield.Solved: the incident is solved, but the team prefers to monitor/check for future issues.Opened/Closed: the ticket was opened only to report an incident that has already been solved.Inactive: the ticket is under the responsibility of an external domain and is no longer under the reporting domain's control.Reopened: the ticket was closed by error, or the problem was erroneously declared to be solved. Data in the History field are very important in this case.Superseded: the ticket has been superseded by another one (for example, a bigger problem that had resulted in many tickets was later merged into a single incident/ticket). TheRELATED_ACTIVITYfield SHOULD include the master ticket reference.
Allowed transitions for TT_STATUS are only those indicated in Figure 2. Possible final states are indicated with (X). 🌈
+------------------+
| Opened/Closed (X)|
+------------------+
|
|
V
+--------------+
/-----------------------| Reopened |<-------------------\
| | |----------\ |
| +--------------+ | |
| ^ | |
| | | |
| V | |
| +-------------------+ | |
| | Superseded (X) | | |
| | or Inactive (X) | | |
| /----------------->| or Cancelled (X) |<---\ | |
| | +-------------------+ | | |
| | ^ | | |
| | | | V |
| | +--------+ | +--------+ |
| | /---------| Opened |----/ | Solved |-----\ |
| | | | |---------------->| | | |
| | | +--------+ +--------+ | |
| | | | ^ | |
V | V | | | |
+---------+ | | | |
| |----------(|)-------------------------/ V V
| Updated | | +------------+
| |----------(|)---------------------------->| |
+---------+ | | Closed (X) |
\----------------------------->| |
+------------+
Figure 2. TT_STATUS Transition Diagram2.2.2. String 💖
The String value is defined by the user of the model. The String data type is implemented as xs:string in the Schema.
2.2.3. Datetime 🦋
Date-time strings are represented by the Datetime data type. Each date-time string identifies a particular instant in time; ranges are not supported.
Date-time strings are formatted according to a subset of ISO 8601:2000 as documented in RFC 3339.
The Datetime data type is implemented as xs:dateTime in the Schema.
3. NTTDM 🧚
In this section, the individual components of the NTTDM will be discussed in detail. This class provides a standardized representation for commonly exchanged Field Name data.
3.1. NTTDM Components 🌸
3.1.1. NTTDM Attributes
The Field Name class has four attributes. Each attribute provides information about a Field Name instance. The attributes that characterize one instance constitute all the information required to form the data model.
DESCRIPTION
This field contains a short description of the Field Name.
TYPE
The TYPE attribute contains information about the type of the Field Name it depends on. The values that it may contain are:
Defined, Free, Multiple, and List.
VALID FORMAT
This attribute contains information about the format of each field. The values that it may contain are:
Predefined String, String, and Datetime.
MANDATORY
This attribute indicates whether the information of each field is required or optional. If the information is required, the MANDATORY field contains the word "YES". If the information is optional, the MANDATORY field contains the word "NO".
3.2. NTTDM Aggregate Classes 👑
3.2.1. NTTDM-Document Class
The NTTDM-Document class is the top-level class in the NTTDM. All NTTDM documents are an instance of this class.
+---------------+
| NTTDM-Document|
+---------------+
| version |<>--{1..*}--[ Ticket ]
| lang |
+---------------+
Figure 3. NTTDM-Document ClassThe aggregate class that constitutes an NTTDM-Document is:
Ticket
One or more. The information related to a single ticket.
The NTTDM-Document class has two attributes:
version
STRING. The value of this attribute MUST be "1.00".
lang
Required.
3.2.2. Ticket Class 🎀
Every ticket is represented by an instance of the Ticket class. This class provides a standardized representation for commonly exchanged TT data.
+---------+
| Ticket |
+---------+
| lang |<>----------[ Partner_ID ]
| |<>----------[ Original_ID ]
| |<>----------[ TT_ID ]
| |<>----------[ TT_Title ]
| |<>----------[ TT_Type ]
| |<>--{0..1}--[ TT_Priority ]
| |<>----------[ TT_Status ]
| |<>--{0..1}--[ TT_Source ]
| |<>----------[ TT_Open_Datetime ]
| |<>----------[ TT_Close_Datetime ]
| |<>----------[ TT_Short_Description ]
| |<>----------[ TT_Long_Description ]
| |<>----------[ Type ]
| |<>----------[ TT_Impact_Assessment ]
| |<>----------[ Start_Datetime ]
| |<>--{0..1}--[ Detect_Datetime ]
| |<>--{0..1}--[ Report_Datetime ]
| |<>----------[ End_Datetime ]
| |<>----------[ TT_Last_Update_Time ]
| |<>--{0..1}--[ Time_Window_Start ]
| |<>--{0..1}--[ Time_Window_End ]
| |<>--{0..1}--[ Work_Plan_Start_Datetime ]
| |<>--{0..1}--[ Work_Plan_End_Datetime ]
| |<>--{0..1}--[ Related_External_Tickets ]
| |<>--{0..1}--[ Additional_Data ]
| |<>--{0..1}--[ Related_Activity ]
| |<>----------[ History ]
| |<>--{0..1}--[ Affected_Community ]
| |<>--{0..1}--[ Affected_Service ]
| |<>----------[ Location ]
| |<>--{0..1}--[ Network_Node ]
| |<>--{0..1}--[ Network_Link_Circuit ]
| |<>--{0..1}--[ End_Line_Location_A ]
| |<>--{0..1}--[ End_Line_Location_B ]
| |<>--{0..1}--[ Open_Engineer ]
| |<>--{0..1}--[ Contact_Engineers ]
| |<>--{0..1}--[ Close_Engineer ]
| |<>--{0..1}--[ Hash ]
+---------+
Figure 4. The Ticket Classlang
Required.
The Field Names are the Aggregate Classes that constitute the NTTDM, and each of them is an element that is characterized by a quadruple (DESCRIPTION, TYPE, VALID FORMAT, MANDATORY).
3.2.3. Ticket Origin Information 🍓
3.2.3.1. PARTNER_ID
+--------------+
| PARTNER_ID |
+--------------+
| DESCRIPTION | The unique ID of the TT source partner.
| TYPE | Multiple.
| VALID FORMAT | String.
| MANDATORY | Yes.
+--------------+
Figure 5. Partner_ID Class3.2.3.2. ORIGINAL_ID
+--------------+
| ORIGINAL_ID |
+--------------+
| DESCRIPTION | The TT ID that was assigned by the party.
| TYPE | Free.
| VALID FORMAT | String.
| MANDATORY | Yes.
+--------------+
Figure 6. Original_ID Class3.2.4. Ticket Information 💜
3.2.4.1. TT_ID
+--------------+
| TT_ID |
+--------------+
| DESCRIPTION | The unique ID of the TT.
| TYPE | As defined below.
| VALID FORMAT | String.
| MANDATORY | Yes.
+--------------+
Figure 7. TT_ID ClassTYPE is constructed as "PARTNER_ID"_"ORIGINAL_ID". PARTNER_ID and ORIGINAL_ID therefore MUST NOT contain an underscore character. 🙈
3.2.4.2. TT_TITLE ✨
okay bestie, the TT_TITLE is the title of the TT 🎀 simple but iconic
+---------------+
| TT_TITLE |
+---------------+
| DESCRIPTION | The title of the TT.
| TYPE | Defined.
| VALID FORMAT | String.
| MANDATORY | Yes.
+---------------+
Figure 8. TT_Title Class3.2.4.3. TT_TYPE 🦋
the TT_TYPE says what kind of TT it is, and it's a Multiple field, so you pick from the predefined strings 💅
+---------------+
| TT_TYPE |
+---------------+
| DESCRIPTION | The type of the TT.
| TYPE | Multiple.
| VALID FORMAT | Predefined String.
| MANDATORY | Yes.
+---------------+
Figure 9. TT_Type Class3.2.4.4. TT_PRIORITY 🔥
TT_PRIORITY is the TT priority. it's Multiple, uses predefined strings, and it's not mandatory, so it's giving optional energy 🌸
+--------------+
| TT_PRIORITY |
+--------------+
| DESCRIPTION | The TT priority.
| TYPE | Multiple.
| VALID FORMAT | Predefined String.
| MANDATORY | No.
+--------------+
Figure 10. TT_Priority Class3.2.4.5. TT_STATUS 💜
TT_STATUS is the TT status. it's Multiple, uses predefined strings, and it IS mandatory, so no skipping this one 🫶
+--------------+
| TT_STATUS |
+--------------+
| DESCRIPTION | The TT status.
| TYPE | Multiple.
| VALID FORMAT | Predefined String.
| MANDATORY | Yes.
+--------------+
Figure 11. TT_Status Class3.2.4.6. TT_SOURCE 🌈
TT_SOURCE tells you where the ticket came from. Multiple, predefined strings, and optional, so it's a lowkey bonus field ✨
+--------------+
| TT_SOURCE |
+--------------+
| DESCRIPTION | The source of the ticket.
| TYPE | Multiple.
| VALID FORMAT | Predefined String.
| MANDATORY | No.
+--------------+
Figure 12. TT_Source Class3.2.4.7. TT_OPEN_DATETIME 🕰️
this one is when the TT got opened. Multiple, Datetime format, and mandatory, because we need to know when the drama started 💀
+------------------+
| TT_OPEN_DATETIME |
+------------------+
| DESCRIPTION | The date and time when the TT was opened.
| TYPE | Multiple.
| VALID FORMAT | Datetime.
| MANDATORY | Yes.
+------------------+
Figure 13. TT_Open_Datetime Class3.2.4.8. TT_CLOSE_DATETIME 🍓
the mirror of the last one: when the TT got closed. Multiple, Datetime, and mandatory, the closing bell has to ring 🔔
+-------------------+
| TT_CLOSE_DATETIME |
+-------------------+
| DESCRIPTION | The date and time when the TT was closed.
| TYPE | Multiple.
| VALID FORMAT | Datetime.
| MANDATORY | Yes.
+-------------------+
Figure 14. TT_Close_Datetime Class3.2.5. Trouble Details 🩷
this section is all about the actual trouble. the what, the when, the how bad 😭
3.2.5.1. TT_SHORT_DESCRIPTION 💅
the short description of the trouble. Multiple, predefined strings, mandatory, so keep it snappy bestie 🎀
+----------------------+
| TT_SHORT_DESCRIPTION |
+----------------------+
| DESCRIPTION | The short description of the trouble.
| TYPE | Multiple.
| VALID FORMAT | Predefined String.
| MANDATORY | Yes.
+----------------------+
Figure 15. TT_Short_Description Class3.2.5.2. TT_LONG_DESCRIPTION 📖
this is where you spill the full tea on the incident or maintenance. it's Free type, String format, and optional, so you can write as much as you want 🧚
+---------------------+
| TT_LONG_DESCRIPTION |
+---------------------+
| DESCRIPTION | The detailed description of the
| | incident/maintenance reported in the TT.
| TYPE | Free.
| VALID FORMAT | String.
| MANDATORY | No.
+---------------------+
Figure 16. TT_Long_Description Class3.2.5.3. TYPE 🌸
the type of the trouble. Multiple, predefined strings, mandatory. it's the plain-named cousin of the TT_TYPE field, which is a whole vibe 🙈
+--------------+
| TYPE |
+--------------+
| DESCRIPTION | The type of the trouble.
| TYPE | Multiple.
| VALID FORMAT | Predefined String.
| MANDATORY | Yes.
+--------------+
Figure 17. Type Class3.2.5.4. TT_IMPACT_ASSESSMENT 💥
the impact of the incident or maintenance. Multiple, predefined strings, and mandatory, because we gotta know how much chaos we're dealing with 👑
+----------------------+
| TT_IMPACT_ASSESSMENT |
+----------------------+
| DESCRIPTION | The impact of the incident/maintenance.
| TYPE | Multiple.
| VALID FORMAT | Predefined String.
| MANDATORY | Yes.
+----------------------+
Figure 18. TT_Impact_Assessment Class3.2.5.5. START_DATETIME ⏰
the date and time that the incident or maintenance started. Multiple, Datetime, mandatory. start time is everything 🦋
+----------------+
| START_DATETIME |
+----------------+
| DESCRIPTION | The date and time that the
| | incident/maintenance started.
| TYPE | Multiple.
| VALID FORMAT | Datetime.
| MANDATORY | Yes.
+----------------+
Figure 19. Start_Datetime Class3.2.5.6. DETECT_DATETIME 🔍
the date and time when the incident was detected. Multiple, Datetime, and optional. the detective era is so real 🕵️♀️
+-------------------+
| DETECT_DATETIME |
+-------------------+
| DESCRIPTION | The date and time when the incident
| | was detected.
| TYPE | Multiple.
| VALID FORMAT | Datetime.
| MANDATORY | No.
+-------------------+
Figure 20. Detect_Datetime Class3.2.5.7. REPORT_DATETIME 📣
the date and time when the incident was reported. Multiple, Datetime, optional. someone's gotta be the one who spills it 📢
+-----------------+
| REPORT_DATETIME |
+-----------------+
| DESCRIPTION | The date and time when the incident
| | was reported.
| TYPE | Multiple.
| VALID FORMAT | Datetime.
| MANDATORY | No.
+-----------------+
Figure 21. Report_Datetime Class3.2.5.8. END_DATETIME 🌙
the date and time when the incident or maintenance ended. Multiple, Datetime, mandatory. every story needs an ending, periodt 💜
+--------------+
| END_DATETIME |
+--------------+
| DESCRIPTION | The date and time when the incident/maintenance
| | ended.
| TYPE | Multiple.
| VALID FORMAT | Datetime.
| MANDATORY | Yes.
+--------------+
Figure 22. End_Datetime Class3.2.5.9. TT_LAST_UPDATE_TIME ⭐
the last date and time the TT got updated. Multiple, Datetime, mandatory. it's the TT's most recent glow-up check 🪞
+---------------------+
| TT_LAST_UPDATE_TIME |
+---------------------+
| DESCRIPTION | The last date and time when the TT was
| | updated.
| TYPE | Multiple.
| VALID FORMAT | Datetime.
| MANDATORY | Yes.
+---------------------+
Figure 23. TT_Last_Update_Time Class3.2.5.10. TIME_WINDOW_START 🪟
the start of the window in which planned maintenance may happen. Multiple, Datetime, and it's only mandatory if TYPE is "Scheduled". so it's conditional, not a blanket rule 🎀
+-------------------+
| TIME_WINDOW_START |
+-------------------+
| DESCRIPTION | The window start time in which planned
| | maintenance may occur.
| TYPE | Multiple.
| VALID FORMAT | Datetime.
| MANDATORY | No, unless TYPE is "Scheduled".
+-------------------+
Figure 24. Time_Window_Start Class3.2.5.11. TIME_WINDOW_END 🪟
the end of that same window. Multiple, Datetime, same deal: only mandatory when TYPE is "Scheduled" 🧸
+-----------------+
| TIME_WINDOW_END |
+-----------------+
| DESCRIPTION | The window end time in which planned
| | maintenance may occur.
| TYPE | Multiple.
| VALID FORMAT | Datetime.
| MANDATORY | No, unless TYPE is "Scheduled".
+-----------------+
Figure 25. Time_Window_End Class3.2.5.12. WORK_PLAN_START_DATETIME 🛠️
the planned (expected) start time of the work, for maintenance. Multiple, Datetime, optional. it's the plan, not the reality, so no pressure 🌷
+--------------------------+
| WORK_PLAN_START_DATETIME |
+--------------------------+
| DESCRIPTION | Work planned (expected): start time
| | in case of maintenance.
| TYPE | Multiple.
| VALID FORMAT | Datetime.
| MANDATORY | No.
+--------------------------+
Figure 26. Work_Plan_Start_Datetime Class3.2.5.13. WORK_PLAN_END_DATETIME 🛠️
the planned (expected) end time of the work, for maintenance. Multiple, Datetime, optional, the other bookend of the plan 🌅
+------------------------+
| WORK_PLAN_END_DATETIME |
+------------------------+
| DESCRIPTION | Work planned (expected): end time
| | in case of maintenance.
| TYPE | Multiple.
| VALID FORMAT | Datetime.
| MANDATORY | No.
+------------------------+
Figure 27. Work_Plan_End_Datetime Classokay this part is a big deal bestie 🚨 the period from WORK_PLAN_START_DATETIME to WORK_PLAN_END_DATETIME MUST be inside the period from TIME_WINDOW_START to TIME_WINDOW_END, and it MUST also be duplicated in {START, END}_DATETIME, even for maintenance. no skipping the copy-paste step 💅
3.2.6. Related Data 🔗
this section is the connections between the TT and everything else in the universe 🌌
3.2.6.1. RELATED_EXTERNAL_TICKETS 🎫
the NOC entity related to the incident. it's a List, uses String format, and it's optional. think of it as the group chat tag 🫶
+--------------------------+
| RELATED_EXTERNAL_TICKETS |
+--------------------------+
| DESCRIPTION | The NOC entity related to the incident.
| TYPE | List.
| VALID FORMAT | String.
| MANDATORY | No.
+--------------------------+
Figure 28. Related_External_Tickets Class3.2.6.2. ADDITIONAL_DATA 🧁
extra info, basically the "oh and also" field. Free type, String, optional. it's giving catch-all energy 🌈
+-----------------+
| ADDITIONAL_DATA |
+-----------------+
| DESCRIPTION | Additional information.
| TYPE | Free.
| VALID FORMAT | String.
| MANDATORY | No.
+-----------------+
Figure 29. Additional_Data Class3.2.6.3. RELATED_ACTIVITY 🧵
the TT IDs of the related incidents. Multiple, String, optional. it's how you link your drama to someone else's drama 🎀
+------------------+
| RELATED_ACTIVITY |
+------------------+
| DESCRIPTION | The TT IDs of the related incidents.
| TYPE | Multiple.
| VALID FORMAT | String.
| MANDATORY | No.
+------------------+
Figure 30. Related_Activity Class3.2.6.4. HISTORY 📜
the necessary actions and events log. Free type, String, and mandatory, so the receipts always get kept 🧾
+--------------+
| HISTORY |
+--------------+
| DESCRIPTION | The necessary actions/events log.
| TYPE | Free.
| VALID FORMAT | String.
| MANDATORY | Yes.
+--------------+
Figure 31. History Class🚨 bestie, read this note carefully. this field MUST NOT be empty when the VALID FORMAT attribute of the TT_STATUS field is anything other than "OPENED" or "OPENED/CLOSED". no empty HISTORY for the spicy statuses 💀
Note: This field MUST NOT be empty when the VALID FORMAT attribute
of the TT_STATUS field is anything other than "OPENED" or
"OPENED/CLOSED".3.2.7. Localization and Impact 🌍
this is the where-and-who section: where it happened, who got affected, and what got knocked out 🌸
3.2.7.1. AFFECTED_COMMUNITY 🏘️
information about the community that was affected by the incident. Free, String, optional. the people behind the outage, basically 🫶
+--------------------+
| AFFECTED_COMMUNITY |
+--------------------+
| DESCRIPTION | Information about the community that was
| | affected by the incident.
| TYPE | Free.
| VALID FORMAT | String.
| MANDATORY | No.
+--------------------+
Figure 32. Affected_Community Class3.2.7.2. AFFECTED_SERVICE 📡
the service that got affected by the incident. Multiple, String, optional. who's offline, lowkey important 😭
+------------------+
| AFFECTED_SERVICE |
+------------------+
| DESCRIPTION | The service that was affected by the
| | incident.
| TYPE | Multiple.
| VALID FORMAT | String.
| MANDATORY | No.
+------------------+
Figure 33. Affected_Service Class3.2.7.3. LOCATION 📍
where the incident or maintenance happened: a Point of Presence (POP) site, a city, that kind of thing. Multiple, String, and mandatory, because a location is a must-have 🗺️
+--------------+
| LOCATION |
+--------------+
| DESCRIPTION | The location (Point of Presence (POP) site,
| | city, etc.) of the incident/maintenance.
| TYPE | Multiple.
| VALID FORMAT | String.
| MANDATORY | Yes.
+--------------+
Figure 34. Location Class3.2.7.4. NETWORK_NODE 🖥️
the NOC network node related to the incident. List, String, optional. it's the specific box that had the bad day 💻
+--------------+
| NETWORK_NODE |
+--------------+
| DESCRIPTION | The NOC network node related to the incident.
| TYPE | List.
| VALID FORMAT | String.
| MANDATORY | No.
+--------------+
Figure 35. Network_Node Class3.2.7.5. NETWORK_LINK_CIRCUIT 🔌
the name of the network line related to the incident. List, String, optional. the cable that started the whole saga 🧶
+----------------------+
| NETWORK_LINK_CIRCUIT |
+----------------------+
| DESCRIPTION | The name of the network line related
| | to the incident.
| TYPE | List.
| VALID FORMAT | String.
| MANDATORY | No.
+----------------------+
Figure 36. Network_Link_Circuit Class3.2.7.6. END_LINE_LOCATION_A 💖
Okay bestie, this one is the A-end of the link 🔗. It's a multiple type, it's a string, and it's not mandatory. Here's the whole class:
+---------------------+
| END_LINE_LOCATION_A |
+---------------------+
| DESCRIPTION | A-end of the link.
| TYPE | Multiple.
| VALID FORMAT | String.
| MANDATORY | No.
+---------------------+Figure 37. End_Line_Location_A Class 🎀
3.2.7.7. END_LINE_LOCATION_B 🦋
And this is the mirror image, the B-end of the link. Same vibes as the A-end: multiple, string, and not mandatory. It's giving symmetry ✨
+---------------------+
| END_LINE_LOCATION_B |
+---------------------+
| DESCRIPTION | B-end of the link.
| TYPE | Multiple.
| VALID FORMAT | String.
| MANDATORY | No.
+---------------------+Figure 38. End_Line_Location_B Class 🌸
3.2.8. Contact Information 📞
Next up is contact info. These fields are all about the humans behind a ticket, which is honestly the most relatable part of the whole thing 🫶
3.2.8.1. OPEN_ENGINEER 🧚
This is the engineer who opened the ticket. It's multiple, it's a string, and it isn't mandatory.
+---------------+
| OPEN_ENGINEER |
+---------------+
| DESCRIPTION | The engineer that opened the ticket.
| TYPE | Multiple.
| VALID FORMAT | String.
| MANDATORY | No.
+---------------+Figure 39. Open_Engineer Class 💜
3.2.8.2. CONTACT_ENGINEERS 🍓
This one is for the engineers responsible for settling the incident. It's a list instead of a single value, so you can have more than one name here 👯♀️ It's a string, and it isn't mandatory.
+-------------------+
| CONTACT_ENGINEERS |
+-------------------+
| DESCRIPTION | The engineers responsible for the incident
| | settlement.
| TYPE | List.
| VALID FORMAT | String.
| MANDATORY | No.
+-------------------+Figure 40. Contact_Engineers Class 🌈
3.2.8.3. CLOSE_ENGINEER 👑
This is the engineer who closed the ticket. The closing chapter, iconic 🥹 It's multiple, a string, and not mandatory.
+----------------+
| CLOSE_ENGINEER |
+----------------+
| DESCRIPTION | The engineer that closed the ticket.
| TYPE | Multiple.
| VALID FORMAT | String.
| MANDATORY | No.
+----------------+Figure 41. Close_Engineer Class ⭐
3.2.9. Security 🔐
Security time, and I'm not playing with it 💀
3.2.9.1. HASH 🔥
This is the encrypted message hash. It's a defined type, it's a string, and it isn't mandatory.
+-------------+
| HASH |
+-------------+
| DESCRIPTION | Encrypted message hash.
| TYPE | Defined.
| VALID FORMAT| String.
| MANDATORY | No.
+-------------+Figure 42. Hash Class 🦋
3.3. NTTDM Representation 🎀
Okay so this is where it all comes together. The trouble tickets (TTs) collected and processed from multiple telecommunications networks get adjusted into one normalized NTTDM. It's giving unified data model energy 💅 Figure 43 shows what that normalized model looks like. The "DESCRIPTION" attribute is implied, so you don't need to spell it out.
+------------------------+--------+------------------+---------+
| FIELD NAME | TYPE |VALID FORMAT |MANDATORY|
+------------------------+--------+------------------+---------+
|PARTNER_ID |MULTIPLE|STRING |YES |
|ORIGINAL_ID |FREE |STRING |YES |
|TT_ID |DEFINED |STRING |YES |
|TT_TITLE |DEFINED |STRING |YES |
|TT_TYPE |MULTIPLE|PREDEFINED STRING |YES |
|TT_PRIORITY |MULTIPLE|PREDEFINED STRING |NO |
|TT_STATUS |MULTIPLE|PREDEFINED STRING |YES |
|TT_SOURCE |MULTIPLE|PREDEFINED STRING |NO |
|TT_OPEN_DATETIME |MULTIPLE|DATETIME |YES |
|TT_CLOSE_DATETIME |MULTIPLE|DATETIME |YES |
|TT_SHORT_DESCRIPTION |MULTIPLE|PREDEFINED STRING |YES |
|TT_LONG_DESCRIPTION |FREE |STRING |NO |
|TYPE |MULTIPLE|PREDEFINED STRING |YES |
|TT_IMPACT_ASSESSMENT |MULTIPLE|PREDEFINED STRING |YES |
|START_DATETIME |MULTIPLE|DATETIME |YES |
|DETECT_DATETIME |MULTIPLE|DATETIME |NO |
|REPORT_DATETIME |MULTIPLE|DATETIME |NO |
|END_DATETIME |MULTIPLE|DATETIME |YES |
|TT_LAST_UPDATE_TIME |MULTIPLE|DATETIME |YES |
|TIME_WINDOW_START |MULTIPLE|DATETIME |NO |
|TIME_WINDOW_END |MULTIPLE|DATETIME |NO |
|WORK_PLAN_START_DATETIME|MULTIPLE|DATETIME |NO |
|WORK_PLAN_END_DATETIME |MULTIPLE|DATETIME |NO |
|RELATED_EXTERNAL_TICKETS|LIST |STRING |NO |
|ADDITIONAL_DATA |FREE |STRING |NO |
|RELATED_ACTIVITY |MULTIPLE|STRING |NO |
|HISTORY |FREE |STRING |YES |
|AFFECTED_COMMUNITY |FREE |STRING |NO |
|AFFECTED_SERVICE |MULTIPLE|STRING |NO |
|LOCATION |MULTIPLE|STRING |YES |
|NETWORK_NODE |LIST |STRING |NO |
|NETWORK_LINK_CIRCUIT |LIST |STRING |NO |
|END_LINE_LOCATION_A |MULTIPLE|STRING |NO |
|END_LINE_LOCATION_B |MULTIPLE|STRING |NO |
|OPEN_ENGINEER |MULTIPLE|STRING |NO |
|CONTACT_ENGINEERS |LIST |STRING |NO |
|CLOSE_ENGINEER |MULTIPLE|STRING |NO |
|HASH |DEFINED |STRING |NO |
+------------------------+--------+------------------+---------+Figure 43. The Field Name Class 💖
4. Internationalization Issues 🌍
Internationalization and localization matter a LOT to the NTTDM 🗣️ Some incidents only get fixed when people work together, and that often means crossing language barriers. The NTTDM helps with this by leaning on XML constructs and by making some deliberate design choices in the data model. Teamwork makes the dream work 🫶
The big win here is that the model gives you a normalized data type that's fully implemented in English, so it's super convenient to use. It also supports free-form text that can be written in any language 🌸 And in the future, it will offer translation services for all of that free-form text. Iconic, honestly ✨
5. Example 🧁
5.1. Link Failure ⚡
Here's a real example of TTs being exchanged in the proposed format, and yes, it's an actual GRNet ticket normalized according to the NTTDM 👀 Any fields that weren't in the original ticket are left blank, so don't be confused if you see some empty spots.
<?xml version="1.0" encoding="UTF-8"?>
<!-- This example describes a link failure that was detected -->
<NTTDM-Document version="1.00" lang="el"
xmlns="urn:ietf:params:xml:ns:nttdm-1.0">
<Ticket>
<Original_ID>5985</Original_ID>
<Partner_ID>01</Partner_ID>
<TT_ID>01_5985</TT_ID>
<TT_Title>Forth Link Failure</TT_Title>
<TT_Type>Operational</TT_Type>
<TT_Status>Closed</TT_Status>
<TT_Open_Datetime>2008-12-16T10:01:15+02:00</TT_Open_Datetime>
<TT_Short_Description>Core Line Fault</TT_Short_Description>
<TT_Long_Description>Forth Link Failure</TT_Long_Description>
<Type>Unscheduled</Type>
<TT_Impact_Assessment>No connectivity</TT_Impact_Assessment>
<Start_Datetime>2008-12-16T09:55:00+02:00</Start_Datetime>
<TT_Last_Update_Time>2008-12-16T15:00:34+02:00</TT_Last_Update_Time>
<Location>HERAKLION</Location>
<History>Optical transmitter was changed</History>
<TT_Close_Datetime>2008-12-16T15:05:00+02:00</TT_Close_Datetime>
<End_Datetime>2008-12-16T15:01:21+02:00</End_Datetime>
<Network_Node>
<Node>FORTH</Node>
</Network_Node>
<Network_Link_Circuit>
<Link_Circuit>FORTH-2</Link_Circuit>
</Network_Link_Circuit>
<Open_Engineer>Dimitris Zisiadis</Open_Engineer>
<Close_Engineer>Guillaume Cessieux</Close_Engineer>
<Contact_Engineers>
<Engineer>Spyros Kopsidas</Engineer>
<Engineer>Chrysostomos Tziouvaras</Engineer>
</Contact_Engineers>
<TT_Priority>High</TT_Priority>
</Ticket>
</NTTDM-Document>6. Sample Implementation: XML Schema 🎀
Here's a sample XML Schema of the NTTDM, so you can see how the pieces snap together 🧚
<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema xmlns="urn:ietf:params:xml:ns:nttdm-0.1"
xmlns:nttdm="urn:ietf:params:xml:ns:nttdm-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:nttdm-1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation
>Trouble Ticket Data Model v-1.0</xs:documentation>
</xs:annotation>
<!--
===============================================================
== NTTDM-Document Class ==
===============================================================
-->
<xs:element name="NTTDM-Document">
<xs:complexType>
<xs:sequence>
<xs:element ref="nttdm:Ticket" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="version" type="xs:string" fixed="1.00"/>
<xs:attribute name="lang" type="xs:language" use="required"/>
</xs:complexType>
</xs:element>
<!--
===============================================================
== Ticket Class ==
===============================================================
-->
<xs:element name="Ticket">
<xs:complexType>
<xs:all>
<xs:element ref="nttdm:Partner_ID"/>
<xs:element ref="nttdm:Original_ID"/>
<xs:element ref="nttdm:TT_ID"/>
<xs:element ref="nttdm:TT_Title"/>
<xs:element ref="nttdm:TT_Type"/>
<xs:element ref="nttdm:TT_Priority" minOccurs="0"/>
<xs:element ref="nttdm:TT_Status"/>
<xs:element ref="nttdm:TT_Source" minOccurs="0"/>
<xs:element ref="nttdm:TT_Open_Datetime"/>
<xs:element ref="nttdm:TT_Close_Datetime"/>
<xs:element ref="nttdm:TT_Short_Description"/>
<xs:element ref="nttdm:TT_Long_Description"/>
<xs:element ref="nttdm:Type"/>
<xs:element ref="nttdm:TT_Impact_Assessment"/>
<xs:element ref="nttdm:Start_Datetime"/>
<xs:element ref="nttdm:Detect_Datetime" minOccurs="0"/>
<xs:element ref="nttdm:Report_Datetime" minOccurs="0"/>
<xs:element ref="nttdm:End_Datetime"/>
<xs:element ref="nttdm:TT_Last_Update_Time"/>
<xs:element ref="nttdm:Time_Window_Start" minOccurs="0"/>
<xs:element ref="nttdm:Time_Window_End" minOccurs="0"/>
<xs:element ref="nttdm:Work_Plan_Start_Datetime" minOccurs="0"/>
<xs:element ref="nttdm:Work_Plan_End_Datetime" minOccurs="0"/>
<xs:element ref="nttdm:Related_External_Tickets" minOccurs="0"/>
<xs:element ref="nttdm:Additional_Data" minOccurs="0"/>
<xs:element ref="nttdm:Related_Activity" minOccurs="0"/>
<xs:element ref="nttdm:History"/>
<xs:element ref="nttdm:Affected_Community" minOccurs="0"/>
<xs:element ref="nttdm:Affected_Service" minOccurs="0"/>
<xs:element ref="nttdm:Location"/>
<xs:element ref="nttdm:Network_Node" minOccurs="0"/>
<xs:element ref="nttdm:Network_Link_Circuit" minOccurs="0"/>
<xs:element ref="nttdm:End_Line_Location_B" minOccurs="0"/>
<xs:element ref="nttdm:Open_Engineer" minOccurs="0"/>
<xs:element ref="nttdm:Contact_Engineers" minOccurs="0"/>
<xs:element ref="nttdm:Close_Engineer" minOccurs="0"/>
<xs:element ref="nttdm:Hash" minOccurs="0"/>
<xs:element ref="nttdm:End_Line_Location_A" minOccurs="0"/>
</xs:all>
<xs:attribute name="lang" type="xs:language"/>
</xs:complexType>
</xs:element>
<!--
===============================================================
== Partner_ID Class ==
===============================================================
-->
<xs:element name="Partner_ID" type="nttdm:string_no_underscore"/>Okay bestie, the schema is giving a whole list of little labeled boxes 📦✨ Each one is a ticket field with its own type, and the last bit defines the custom types they point to 💅
<!--
===============================================================
== Original_ID Class ==
===============================================================
-->
<xs:element name="Original_ID" type="nttdm:string_no_underscore"/>
<!--
===============================================================
== TT_ID Class ==
===============================================================
-->
<xs:element name="TT_ID" type="xs:string"/>
<!--
===============================================================
== TT_Title Class ==
===============================================================
-->
<xs:element name="TT_Title" type="xs:string"/>
<!--
===============================================================
== TT_Type Class ==
===============================================================
-->
<xs:element name="TT_Type" type="nttdm:eTT_Type"/>
<!--
===============================================================
== TT_Priority Class ==
===============================================================
-->
<xs:element name="TT_Priority" type="nttdm:eTT_Priority"/>
<!--
===============================================================
== TT_Status Class ==
===============================================================
-->
<xs:element name="TT_Status" type="nttdm:eTT_Status"/>
<!--
===============================================================
== TT_Source Class ==
===============================================================
-->
<xs:element name="TT_Source" type="nttdm:eTT_Source"/>
<!--
===============================================================
== TT_Open_Datetime Class ==
===============================================================
-->
<xs:element name="TT_Open_Datetime" type="xs:dateTime"/>
<!--
===============================================================
== TT_Close_Datetime Class ==
===============================================================
-->
<xs:element name="TT_Close_Datetime" type="xs:dateTime"/>
<!--
===============================================================
== TT_Short_Description Class ==
===============================================================
-->
<xs:element name="TT_Short_Description"
type="nttdm:eTT_Short_Description"/>
<!--
===============================================================
== TT_Long_Description Class ==
===============================================================
-->
<xs:element name="TT_Long_Description" type="xs:string"/>
<!--
===============================================================
== Type Class ==
===============================================================
-->
<xs:element name="Type" type="nttdm:eType"/>
<!--
===============================================================
== TT_Impact_Assessment Class ==
===============================================================
-->
<xs:element name="TT_Impact_Assessment"
type="nttdm:eTT_Impact_Assessment"/>
<!--
===============================================================
== Start_Datetime Class ==
===============================================================
-->
<xs:element name="Start_Datetime" type="xs:dateTime"/>
<!--
===============================================================
== Detect_Datetime Class ==
===============================================================
-->
<xs:element name="Detect_Datetime" type="xs:dateTime"/>
<!--
===============================================================
== Report_Datetime Class ==
===============================================================
-->
<xs:element name="Report_Datetime" type="xs:dateTime"/>
<!--
===============================================================
== End_Datetime Class ==
===============================================================
-->
<xs:element name="End_Datetime" type="xs:dateTime"/>
<!--
===============================================================
== TT_Last_Update_Time Class ==
===============================================================
-->
<xs:element name="TT_Last_Update_Time" type="xs:dateTime"/>
<!--
===============================================================
== Time_Window_Start Class ==
===============================================================
-->
<xs:element name="Time_Window_Start" type="xs:dateTime"/>
<!--
===============================================================
== Time_Window_End Class ==
===============================================================
-->
<xs:element name="Time_Window_End" type="xs:dateTime"/>
<!--
===============================================================
== Work_Plan_Start_Datetime Class ==
===============================================================
-->
<xs:element name="Work_Plan_Start_Datetime" type="xs:dateTime"/>
<!--
===============================================================
== Work_Plan_End_Datetime Class ==
===============================================================
-->
<xs:element name="Work_Plan_End_Datetime" type="xs:dateTime"/>
<!--
===============================================================
== Related_External_Tickets Class ==
===============================================================
-->
<xs:element name="Related_External_Tickets"
type="nttdm:eRelated_External_Tickets"/>
<!--
===============================================================
== Additional_Data Class ==
===============================================================
-->
<xs:element name="Additional_Data" type="xs:string"/>
<!--
===============================================================
== Related_Activity Class ==
===============================================================
-->
<xs:element name="Related_Activity"
type="nttdm:eRelated_Activity"/>
<!--
===============================================================
== History Class ==
===============================================================
-->
<xs:element name="History" type="xs:string"/>
<!--
===============================================================
== Affected_Community Class ==
===============================================================
-->
<xs:element name="Affected_Community" type="xs:string"/>
<!--
===============================================================
== Affected_Service Class ==
===============================================================
-->
<xs:element name="Affected_Service" type="xs:string"/>
<!--
===============================================================
== Location Class ==
===============================================================
-->
<xs:element name="Location" type="xs:string"/>
<!--
===============================================================
== Network_Node Class ==
===============================================================
-->
<xs:element name="Network_Node" type="nttdm:eNodes"/>
<!--
===============================================================
== Network_Link_Circuit Class ==
===============================================================
-->
<xs:element name="Network_Link_Circuit"
type="nttdm:eNetwork_Link_Circuit"/>
<!--
===============================================================
== End_Line_Location_A Class ==
===============================================================
-->
<xs:element name="End_Line_Location_A" type="xs:string"/>
<!--
===============================================================
== End_Line_Location_B Class ==
===============================================================
-->
<xs:element name="End_Line_Location_B" type="xs:string"/>
<!--
===============================================================
== Open_Engineer Class ==
===============================================================
-->
<xs:element name="Open_Engineer" type="xs:string"/>
<!--
===============================================================
== Contact_Engineers Class ==
===============================================================
-->
<xs:element name="Contact_Engineers" type="nttdm:eEngineers"/>
<!--
===============================================================
== Close_Engineer Class ==
===============================================================
-->
<xs:element name="Close_Engineer" type="xs:string"/>
<!--
===============================================================
== Hash Class ==
===============================================================
-->
<xs:element name="Hash" type="xs:string"/>
<!--
===============================================================
== Custom types definition ==
===============================================================
-->
<xs:simpleType name="string_no_underscore">
<xs:restriction base="xs:string">
<xs:pattern value="[^_]*"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="eRelated_External_Tickets">
<xs:sequence>
<xs:element name="TTid" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="eRelated_Activity">
<xs:sequence>
<xs:element name="TT" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="eNodes">
<xs:sequence>
<xs:element name="Node" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="eNetwork_Link_Circuit">
<xs:sequence>
<xs:element name="Link_Circuit" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType> <xs:complexType name="eEngineers">
<xs:sequence>
<xs:element name="Engineer" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="eTT_Type">
<xs:restriction base="xs:string">
<xs:enumeration value="Operational"/>
<xs:enumeration value="Informational"/>
<xs:enumeration value="Administrative"/>
<xs:enumeration value="Test"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="eType">
<xs:restriction base="xs:string">
<xs:enumeration value="Scheduled"/>
<xs:enumeration value="Unscheduled"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="eTT_Priority">
<xs:restriction base="xs:string">
<xs:enumeration value="Low"/>
<xs:enumeration value="Medium"/>
<xs:enumeration value="High"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="eTT_Short_Description">
<xs:restriction base="xs:string">
<xs:enumeration value="Core Line Fault"/>
<xs:enumeration value="Access Line Fault"/>
<xs:enumeration value="Degraded Service"/>
<xs:enumeration value="Router Hardware Fault"/>
<xs:enumeration value="Router Software Fault"/>
<xs:enumeration value="Routing Problem"/>
<xs:enumeration value="Undefined Problem"/>
<xs:enumeration value="Network Congestion"/>
<xs:enumeration value="Client Upgrade"/>
<xs:enumeration value="IPv6"/>
<xs:enumeration value="QoS"/>
<xs:enumeration value="VoIP"/>
<xs:enumeration value="Other"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="eTT_Impact_Assessment">
<xs:restriction base="xs:string">
<xs:enumeration value="No impact"/>
<xs:enumeration value="Reduced redundancy"/>
<xs:enumeration value="Minor performance impact"/>
<xs:enumeration value="Severe performance impact"/>
<xs:enumeration value="No connectivity"/>
<xs:enumeration value="On backup"/>
<xs:enumeration value="At risk"/>
<xs:enumeration value="Unknown"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="eTT_Status">
<xs:restriction base="xs:string">
<xs:enumeration value="Opened"/>
<xs:enumeration value="Updated"/>
<xs:enumeration value="Closed"/>
<xs:enumeration value="Solved"/>
<xs:enumeration value="Opened/Closed"/>
<xs:enumeration value="Inactive"/>
<xs:enumeration value="Cancelled"/>
<xs:enumeration value="Reopened"/>
<xs:enumeration value="Superseded"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="eTT_Source">
<xs:restriction base="xs:string">
<xs:enumeration value="Users"/>
<xs:enumeration value="Monitoring"/>
<xs:enumeration value="Other NOC"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>7. Security Considerations 🔐
Okay bestie, the NTTDM data model is basically a data model plus the XML Schema for trouble ticket normalization, so the NTTDM itself does not raise any security concerns 💅. BUT, network TTs can carry sensitive stuff like IP addresses, contact details, authentication details, and which commercial providers are involved, all about flagship institutions like military and health centres 😭. So some security issues SHOULD be considered 🚨.
The security considerations MAY involve measures during the exchange as well as during processing of the information ✨.
The HASH field is meant to give the exchanged tickets an integrity insurance attribute 🛡️. However, it alone does not ensure integrity 💀.
Confidentiality MAY be ensured by encrypting whole tickets or only some parts of them 🔒. This could let meaningful tickets be disclosed while only the sensitive information stays protected, which is very clever 🧚.
Peer entity authentication SHOULD be provided in order to establish a session with data origin authentication, no matter how the TTs are exchanged 💜. That could be through email, web forms, or a Simple Object Access Protocol (SOAP) service. SOAP is considered the better choice 👑, though the model itself does not specify the communications requirements 🙈.
The underlying communications service MUST provide guarantees to properly address integrity, confidentiality, and peer entity authentication 🫶. The selection of the enforcing mechanisms is not in the scope of this document, so the choice is up to the implementers 🍓.
For data processing security, each participating organization MAY use its own privacy policy as part of its own data processing system 🌸. This approach avoids any interoperability issues and does not pose any extra burden for adopting the current scheme into the operational procedures of the NOCs ✨. Unauthorized and inappropriate usage MUST be avoided 🚫. No cap, this part is serious!!
8. IANA Considerations 🦋
This document uses URNs to describe an XML namespace and Schema conforming to a registry mechanism described in [7] 🌈.
Registration for the NTTDM namespace:
- URI:
urn:ietf:params:xml:ns:nttdm-1.0 - Registrant Contact: See the first author listed in the "Authors' Addresses" section of this document.
- XML: None. Namespace URIs do not represent an XML specification.
Registration for the NTTDM XML Schema:
- URI:
urn:ietf:params:xml:schema:nttdm-1.0 - Registrant Contact: See the first author listed in the "Authors' Addresses" section of this document.
- XML: See the XML Schema in Section 6 of this document.
9. Contributors 🎀
Leandros Tassiulas
Centre for Research and Technology Hellas
6th km Thermi-Thessaloniki, 57001
HellasEMail: leandros@uth.gr
Chrysostomos Tziouvaras
Greek Research and Technology Network
56, Mesogion Av. 11527, Athens
HellasEMail: tziou@grnet.gr
Xavier Jeannin
National Centre for Scientific Research
Network Unit - UREC
FranceEMail: Xavier.Jeannin@urec.cnrs.fr
10. Acknowledgements 🫶
The following groups and individuals contributed substantially to this document and are gratefully acknowledged 💖:
- Toby Rodwell and Emma Apted (DANTE)
- Claudio Allocchio, Gloria Vuagnin, and Claudia Battista (GARR)
- Karin Schauerhammer and Robert Stoy (DFN)
11. References 📚
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation, 26 November 2008, http://www.w3.org/TR/2008/REC-xml-20081126.
[3] World Wide Web Consortium, "XML Schema Part 0: Primer Second Edition", W3C Recommendation, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/.
[4] World Wide Web Consortium, "XML Schema Part 1: Structures Second Edition", W3C Recommendation, 28 October 2004, http://www.w3.org/TR/xmlschema-1/.
[5] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, 28 October 2004, http://www.w3.org/TR/xmlschema-2/.
[6] World Wide Web Consortium, "Namespaces in XML 1.0 (Third Edition)", W3C Recommendation, 8 December 2009, http://www.w3.org/TR/2009/REC-xml-names-20091208/.
[7] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
11.2. Informative References
[8] Enabling Grids for E-sciencE, http://www.eu-egee.org/.
[9] Enabling Grids for E-sciencE, "ENOC, EGEE Network Operation Centre", http://technical.eu-egee.org/index.php?id=353.
[10] Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified Modeling Language Reference Manual," ISBN 020130998X, Addison-Wesley, 1998.
[11] Johnson, D., "NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS")", RFC 1297, January 1992.
Authors' Addresses 💌
Dimitris Zisiadis (editor)
Centre for Research and Technology Hellas
6th km Thermi-Thessaloniki, 57001
HellasEMail: dzisiadis@iti.gr
Spyros Kopsidas (editor)
Centre for Research and Technology Hellas
6th km Thermi-Thessaloniki, 57001
HellasEMail: spyros@uth.gr
Matina Tsavli (editor)
Centre for Research and Technology Hellas
6th km Thermi-Thessaloniki, 57001
HellasEMail: sttsavli@uth.gr
Guillaume Cessieux (editor)
Computer Centre of National Institute for
Nuclear Physics and Particle Physics (IN2P3-CC)
FranceEMail: Guillaume.Cessieux@cc.in2p3.fr
That's the whole spec, bestie!! 🌈✨💅
📦 where this page comes from
- ietf: rfc6137 2011-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms