summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6137.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6137.txt')
-rw-r--r--doc/rfc/rfc6137.txt2579
1 files changed, 2579 insertions, 0 deletions
diff --git a/doc/rfc/rfc6137.txt b/doc/rfc/rfc6137.txt
new file mode 100644
index 0000000..594ee8f
--- /dev/null
+++ b/doc/rfc/rfc6137.txt
@@ -0,0 +1,2579 @@
+
+
+
+
+
+
+Independent Submission D. Zisiadis, Ed.
+Request for Comments: 6137 S. Kopsidas, Ed.
+Category: Experimental M. Tsavli, Ed.
+ISSN: 2070-1721 CERTH
+ G. Cessieux, Ed.
+ CNRS
+ February 2011
+
+
+ The Network Trouble Ticket Data Model (NTTDM)
+
+Abstract
+
+ Handling multiple sets of network trouble tickets (TTs) originating
+ from different participants' inter-connected network environments
+ poses a series of challenges for the involved institutions. A Grid
+ is a good example of such a multi-domain project. Each of the
+ participants follows different procedures for handling trouble in its
+ domain, according to the local technical and linguistic profile. The
+ TT systems of the participants collect, represent, and disseminate TT
+ information in different formats.
+
+ As a result, management of the daily workload by a central Network
+ Operation Centre (NOC) is a challenge on its own. Normalization of
+ TTs to a common format at the central NOC can ease presentation,
+ storing, and handling of the TTs. In the present document, we
+ provide a model for automating the collection and normalization of
+ the TT received by multiple networks forming the Grid. Each of the
+ participants is using its home TT system within its domain for
+ handling trouble incidents, whereas the central NOC is gathering the
+ tickets in the normalized format for repository and handling. XML is
+ used as the common representation language. 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
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This is a contribution to the RFC Series, independently
+ of any other RFC stream. The RFC Editor has chosen to publish this
+ document at its discretion and makes 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; see Section 2 of RFC 5741.
+
+
+
+Zisiadis, et al. Experimental [Page 1]
+
+RFC 6137 NTTDM February 2011
+
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained 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 of this document. Please review these documents
+ carefully, as 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
+
+
+
+Zisiadis, et al. Experimental [Page 2]
+
+RFC 6137 NTTDM February 2011
+
+
+ 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
+
+
+
+
+Zisiadis, et al. Experimental [Page 3]
+
+RFC 6137 NTTDM February 2011
+
+
+ 11. References ....................................................45
+ 11.1. Normative References .....................................45
+ 11.2. Informative References ...................................45
+
+1. Introduction
+
+ Problem-impact assessment, reporting, identification, and handling,
+ as well as dissemination of trouble information and delegation of
+ authority, are some of the main tasks that have to be implemented by
+ the members of a Grid in order to successfully manage the network and
+ maintain operational efficiency of the services offered to their
+ users.
+
+ Different TT systems are used by each network domain, delivering TTs
+ in alternate formats, while the TT load is growing proportionally
+ with network size and serviced users.
+
+ We hereby define a data model for TT normalization -- the Network
+ Trouble Ticket Data Model (NTTDM) -- initially targeted for network
+ providers serving EGEE [8]. The model is designed in accordance with
+ RFC 1297 [11] and meets requirements of the multiple TT systems used.
+
+ The NTTDM
+
+ o is both effective and comprehensive, as it compensates for the
+ core activities of the Network Operation Centres (NOCs). It is
+ also dynamic, allowing additional options to be included in the
+ future, according to demand.
+
+ o provides an XML representation for conveying incident information
+ across administrative domains between parties that have an
+ operational responsibility of remediation or a "watch-and-warn"
+ policy over a defined constituency.
+
+ o encodes information about hosts, networks, and the services
+ running on these systems; attack methodology and associated
+ forensic evidence; impact of the activity; and limited approaches
+ for documenting workflow.
+
+ o aims to simplify TT exchange within the boundaries of a Grid and
+ to enhance 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 imparts network
+ status cognizance by modeling collaboration and information
+ exchange among operators.
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 4]
+
+RFC 6137 NTTDM February 2011
+
+
+ o provides a common format that allows GOCs as well as all
+ participating NOCs to store, exchange, manage, and analyze TTs
+ (assessment of TT impact).
+
+ o provides increased automation in handling a TT, since the network
+ operators have 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 this support
+ activity was to enhance the ENOC (EGEE Network Operation Centre) [9]
+ procedures for better overall network coordination of the Grid.
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [1].
+
+ The NTTDM uses specific keywords to describe the various data
+ components. These keywords 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:
+
+ 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
+
+
+
+
+Zisiadis, et al. Experimental [Page 5]
+
+RFC 6137 NTTDM February 2011
+
+
+ UML: Unified Modeling Language
+
+ XML: Extensible Markup Language
+
+1.2. Notations
+
+ The NTTDM is specified in two ways: as an abstract data model and as
+ an XML Schema. Section 3 provides a Unified Modeling Language (UML)
+ [10] model describing the individual classes and their relationship
+ with each other. The semantics of each class are discussed and their
+ attributes explained. In Section 6, this UML model is converted into
+ an XML Schema [2] [3] [4] [5]. A specific namespace [6] is also
+ defined.
+
+ The term "XML document" refers to any instance of an XML Document.
+ The term "NTTDM document" refers to specific elements and attributes
+ of the NTTDM Schema. Finally, the terms "class" and "element" are
+ used interchangeably to reference either a given UML class in the
+ data model or its corresponding Schema implementation.
+
+1.3. About the Network Trouble Ticket Data Model
+
+ The NTTDM is a data representation that provides a framework for
+ normalizing and sharing information among network operators and the
+ GOC regarding troubles within the Grid boundaries. There has been a
+ lot of thought processing during the design of the data model:
+
+ o The data model serves as a common storage and exchange format.
+
+ o Every NOC still uses its home TT system for network management
+ within its area of control.
+
+ o As there is no universally adopted definition for a trouble, in
+ the NTTDM definition, the term is used with a comprehensive
+ meaning to cover all NOCs.
+
+ o Handling every possible definition of a trouble incident would
+ call for an extremely expanded and complex data model. Therefore,
+ the NTTDM's purpose is to serve as the basis for normalizing and
+ exchanging TTs. It is flexible and expressive in order to ensure
+ that specific NOC requirements are met. Specific NOC information
+ is kept outside the NTTDM, and external databases can be used to
+ feed it.
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 6]
+
+RFC 6137 NTTDM February 2011
+
+
+ o The domain of managing the information is not fully standardized
+ and must rely on free-form textual descriptions. The NTTDM
+ attempts to strike a balance between supporting this free-form
+ content, while 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 the management of a
+ general Grid environment. The already used TT formats influenced the
+ design of the NTTDM.
+
+1.4. About the Network Trouble Ticket Implementation
+
+ Here we describe an example of a typical use case.
+
+ The Grid project EGEE manages its infrastructure as a network overlay
+ over the European National Research and Educational Networks (NRENs)
+ and wants to be able to warn EGEE sites of the unavailability of the
+ network. 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
+ such a heavy load. Thanks to the NTTDM, the EGEE NOC can automate
+ the TT workflow:
+
+ o The TT is filtered, sorted, and stored in a local database (DB).
+
+ o The TT's impact on the Grid is assessed.
+
+ o 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 used
+ within EGEE. Other Grids are free to use it and report comments to
+ the authors. After enough experimentation, we would like to advance
+ it to the Standards Track.
+
+2. NTTDM Types and Definitions
+
+ The various data elements of the TT data model are typed. This
+ section discusses these data types. When possible, native Schema
+ data types were adopted, but for more complicated formats, regular
+ expressions or external standards were used.
+
+
+
+
+Zisiadis, et al. Experimental [Page 7]
+
+RFC 6137 NTTDM February 2011
+
+
+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 that the data model provides a means 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 that the value can be freely chosen.
+
+ All Free strings SHOULD have as an attribute the language used.
+
+ The Free data type is implemented as "Free" in the Schema.
+
+2.1.3. Multiple
+
+ The Multiple data type consists of one value among multiple fixed
+ values.
+
+ The Multiple data type is implemented as "Multiple" in the Schema.
+
+2.1.4. List
+
+ "List" means many values among multiple fixed values. The List data
+ type is implemented as "List" in the Schema.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 8]
+
+RFC 6137 NTTDM February 2011
+
+
+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 such 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 Values
+
+ The Predefined String data type is implemented as "xs:string" in the
+ Schema with a sequence of enumerations for the allowed values.
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 9]
+
+RFC 6137 NTTDM February 2011
+
+
+2.2.1.1. Definitions of the Predefined Values
+
+ TT_TYPE
+
+ o Operational: for network incident and maintenance only.
+
+ o Informational: information about the TT system or the exchange
+ interface (maintenance, upgrade).
+
+ o Administrative: information about the access to the TT system
+ (credentials) or the exchange interface.
+
+ o Test: to test the TT system or the exchange interface, etc.
+
+ TYPE
+
+ o Scheduled: the incident was scheduled to happen.
+
+ o Unscheduled: the incident was unscheduled.
+
+ TT_PRIORITY
+
+ o Low: the TT priority is low.
+
+ o Medium: the TT priority is medium.
+
+ o High: the TT priority is high.
+
+ TT_SHORT_DESCRIPTION
+
+ o Core Line Fault: malfunction of a high-bandwidth core line.
+
+ o Access Line Fault: malfunction of a medium-bandwidth access line.
+
+ o Degraded Service.
+
+ o Router Hardware Fault: malfunction of the router hardware.
+
+ o Router Software Fault: malfunction of the router software.
+
+ o Routing Problem: incident regarding the routing service.
+
+ o Undefined Problem: nature of the problem not identified.
+
+ o Network Congestion: problem due to traffic at the network
+ (blocked).
+
+ o Client Upgrade: incidents regarding client/services upgrade.
+
+
+
+Zisiadis, et al. Experimental [Page 10]
+
+RFC 6137 NTTDM February 2011
+
+
+ o IPv6: incident regarding the IPv6 network.
+
+ o QoS: incident regarding the Quality of Service (QoS) of the
+ network.
+
+ o VoIP: incident regarding Voice over IP (VoIP).
+
+ o Other: non-listed incident.
+
+ TT_IMPACT_ASSESSMENT
+
+ o No impact: the incident does not cause any impacts.
+
+ o Reduced redundancy: the incident reduces network redundancy.
+
+ o Minor performance impact: the incident causes a minor performance
+ impact.
+
+ o Severe performance impact: the incident causes a severe
+ performance impact.
+
+ o No connectivity: the incident causes connectivity failure.
+
+ o On backup: the incident causes a malfunction of backup services.
+
+ o At risk: the incident should not have any impact but could
+ possibly cause some trouble.
+
+ o Unknown: the nature of the impact is not identified.
+
+ TT_STATUS
+
+ o Opened: the ticket is opened.
+
+ o Closed: the ticket is closed.
+
+ o Updated: the ticket's contents have been updated.
+
+ o Cancelled: the ticket has been opened twice; one of the tickets is
+ cancelled, and a relationship between them is defined via the
+ RELATED_ACTIVITY field.
+
+ o Solved: the incident is solved, but the team prefers to
+ monitor/check for future issues.
+
+ o Opened/Closed: the ticket was opened only to report an incident
+ that has already been solved.
+
+
+
+
+Zisiadis, et al. Experimental [Page 11]
+
+RFC 6137 NTTDM February 2011
+
+
+ o Inactive: the ticket is under the responsibility of an external
+ domain and is no longer under the reporting domain's control.
+
+ o 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.
+
+ o 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). The RELATED_ACTIVITY
+ field 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 12]
+
+RFC 6137 NTTDM February 2011
+
+
+ +------------------+
+ | 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 Diagram
+
+2.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.
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 13]
+
+RFC 6137 NTTDM February 2011
+
+
+ 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".
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 14]
+
+RFC 6137 NTTDM February 2011
+
+
+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 Class
+
+ The 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 15]
+
+RFC 6137 NTTDM February 2011
+
+
+ +---------+
+ | 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 Class
+
+ lang
+
+ Required.
+
+
+
+Zisiadis, et al. Experimental [Page 16]
+
+RFC 6137 NTTDM February 2011
+
+
+ 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 Class
+
+3.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 Class
+
+3.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 Class
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 17]
+
+RFC 6137 NTTDM February 2011
+
+
+ TYPE 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
+
+ +---------------+
+ | TT_TITLE |
+ +---------------+
+ | DESCRIPTION | The title of the TT.
+ | TYPE | Defined.
+ | VALID FORMAT | String.
+ | MANDATORY | Yes.
+ +---------------+
+
+ Figure 8. TT_Title Class
+
+3.2.4.3. TT_TYPE
+
+ +---------------+
+ | TT_TYPE |
+ +---------------+
+ | DESCRIPTION | The type of the TT.
+ | TYPE | Multiple.
+ | VALID FORMAT | Predefined String.
+ | MANDATORY | Yes.
+ +---------------+
+
+ Figure 9. TT_Type Class
+
+3.2.4.4. TT_PRIORITY
+
+ +--------------+
+ | TT_PRIORITY |
+ +--------------+
+ | DESCRIPTION | The TT priority.
+ | TYPE | Multiple.
+ | VALID FORMAT | Predefined String.
+ | MANDATORY | No.
+ +--------------+
+
+ Figure 10. TT_Priority Class
+
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 18]
+
+RFC 6137 NTTDM February 2011
+
+
+3.2.4.5. TT_STATUS
+
+ +--------------+
+ | TT_STATUS |
+ +--------------+
+ | DESCRIPTION | The TT status.
+ | TYPE | Multiple.
+ | VALID FORMAT | Predefined String.
+ | MANDATORY | Yes.
+ +--------------+
+
+ Figure 11. TT_Status Class
+
+3.2.4.6. TT_SOURCE
+
+ +--------------+
+ | TT_SOURCE |
+ +--------------+
+ | DESCRIPTION | The source of the ticket.
+ | TYPE | Multiple.
+ | VALID FORMAT | Predefined String.
+ | MANDATORY | No.
+ +--------------+
+
+ Figure 12. TT_Source Class
+
+3.2.4.7. TT_OPEN_DATETIME
+
+ +------------------+
+ | 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 Class
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 19]
+
+RFC 6137 NTTDM February 2011
+
+
+3.2.4.8. TT_CLOSE_DATETIME
+
+ +-------------------+
+ | 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 Class
+
+3.2.5. Trouble Details
+
+3.2.5.1. TT_SHORT_DESCRIPTION
+
+ +----------------------+
+ | TT_SHORT_DESCRIPTION |
+ +----------------------+
+ | DESCRIPTION | The short description of the trouble.
+ | TYPE | Multiple.
+ | VALID FORMAT | Predefined String.
+ | MANDATORY | Yes.
+ +----------------------+
+
+ Figure 15. TT_Short_Description Class
+
+3.2.5.2. TT_LONG_DESCRIPTION
+
+ +---------------------+
+ | 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 Class
+
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 20]
+
+RFC 6137 NTTDM February 2011
+
+
+3.2.5.3. TYPE
+
+ +--------------+
+ | TYPE |
+ +--------------+
+ | DESCRIPTION | The type of the trouble.
+ | TYPE | Multiple.
+ | VALID FORMAT | Predefined String.
+ | MANDATORY | Yes.
+ +--------------+
+
+ Figure 17. Type Class
+
+3.2.5.4. TT_IMPACT_ASSESSMENT
+
+ +----------------------+
+ | TT_IMPACT_ASSESSMENT |
+ +----------------------+
+ | DESCRIPTION | The impact of the incident/maintenance.
+ | TYPE | Multiple.
+ | VALID FORMAT | Predefined String.
+ | MANDATORY | Yes.
+ +----------------------+
+
+ Figure 18. TT_Impact_Assessment Class
+
+3.2.5.5. START_DATETIME
+
+ +----------------+
+ | START_DATETIME |
+ +----------------+
+ | DESCRIPTION | The date and time that the
+ | | incident/maintenance started.
+ | TYPE | Multiple.
+ | VALID FORMAT | Datetime.
+ | MANDATORY | Yes.
+ +----------------+
+
+ Figure 19. Start_Datetime Class
+
+
+
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 21]
+
+RFC 6137 NTTDM February 2011
+
+
+3.2.5.6. DETECT_DATETIME
+
+ +-------------------+
+ | DETECT_DATETIME |
+ +-------------------+
+ | DESCRIPTION | The date and time when the incident
+ | | was detected.
+ | TYPE | Multiple.
+ | VALID FORMAT | Datetime.
+ | MANDATORY | No.
+ +-------------------+
+
+ Figure 20. Detect_Datetime Class
+
+3.2.5.7. REPORT_DATETIME
+
+ +-----------------+
+ | REPORT_DATETIME |
+ +-----------------+
+ | DESCRIPTION | The date and time when the incident
+ | | was reported.
+ | TYPE | Multiple.
+ | VALID FORMAT | Datetime.
+ | MANDATORY | No.
+ +-----------------+
+
+ Figure 21. Report_Datetime Class
+
+3.2.5.8. END_DATETIME
+
+ +--------------+
+ | END_DATETIME |
+ +--------------+
+ | DESCRIPTION | The date and time when the incident/maintenance
+ | | ended.
+ | TYPE | Multiple.
+ | VALID FORMAT | Datetime.
+ | MANDATORY | Yes.
+ +--------------+
+
+ Figure 22. End_Datetime Class
+
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 22]
+
+RFC 6137 NTTDM February 2011
+
+
+3.2.5.9. TT_LAST_UPDATE_TIME
+
+ +---------------------+
+ | 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 Class
+
+3.2.5.10. TIME_WINDOW_START
+
+ +-------------------+
+ | 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 Class
+
+3.2.5.11. TIME_WINDOW_END
+
+ +-----------------+
+ | 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 Class
+
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 23]
+
+RFC 6137 NTTDM February 2011
+
+
+3.2.5.12. WORK_PLAN_START_DATETIME
+
+ +--------------------------+
+ | 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 Class
+
+3.2.5.13. WORK_PLAN_END_DATETIME
+
+ +------------------------+
+ | 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 Class
+
+ The period delimited by WORK_PLAN_START_DATETIME and
+ WORK_PLAN_END_DATETIME MUST be included in the period delimited by
+ TIME_WINDOW_START and TIME_WINDOW_END, and duplicated with {START,
+ END}_DATETIME, even in case of maintenance.
+
+3.2.6. Related Data
+
+3.2.6.1. RELATED_EXTERNAL_TICKETS
+
+ +--------------------------+
+ | RELATED_EXTERNAL_TICKETS |
+ +--------------------------+
+ | DESCRIPTION | The NOC entity related to the incident.
+ | TYPE | List.
+ | VALID FORMAT | String.
+ | MANDATORY | No.
+ +--------------------------+
+
+ Figure 28. Related_External_Tickets Class
+
+
+
+
+Zisiadis, et al. Experimental [Page 24]
+
+RFC 6137 NTTDM February 2011
+
+
+3.2.6.2. ADDITIONAL_DATA
+
+ +-----------------+
+ | ADDITIONAL_DATA |
+ +-----------------+
+ | DESCRIPTION | Additional information.
+ | TYPE | Free.
+ | VALID FORMAT | String.
+ | MANDATORY | No.
+ +-----------------+
+
+ Figure 29. Additional_Data Class
+
+3.2.6.3. RELATED_ACTIVITY
+
+ +------------------+
+ | RELATED_ACTIVITY |
+ +------------------+
+ | DESCRIPTION | The TT IDs of the related incidents.
+ | TYPE | Multiple.
+ | VALID FORMAT | String.
+ | MANDATORY | No.
+ +------------------+
+
+ Figure 30. Related_Activity Class
+
+3.2.6.4. HISTORY
+
+ +--------------+
+ | HISTORY |
+ +--------------+
+ | DESCRIPTION | The necessary actions/events log.
+ | TYPE | Free.
+ | VALID FORMAT | String.
+ | MANDATORY | Yes.
+ +--------------+
+
+ Figure 31. History Class
+
+ 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".
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 25]
+
+RFC 6137 NTTDM February 2011
+
+
+3.2.7. Localization and Impact
+
+3.2.7.1. AFFECTED_COMMUNITY
+
+ +--------------------+
+ | AFFECTED_COMMUNITY |
+ +--------------------+
+ | DESCRIPTION | Information about the community that was
+ | | affected by the incident.
+ | TYPE | Free.
+ | VALID FORMAT | String.
+ | MANDATORY | No.
+ +--------------------+
+
+ Figure 32. Affected_Community Class
+
+3.2.7.2. AFFECTED_SERVICE
+
+ +------------------+
+ | AFFECTED_SERVICE |
+ +------------------+
+ | DESCRIPTION | The service that was affected by the
+ | | incident.
+ | TYPE | Multiple.
+ | VALID FORMAT | String.
+ | MANDATORY | No.
+ +------------------+
+
+ Figure 33. Affected_Service Class
+
+3.2.7.3. LOCATION
+
+ +--------------+
+ | 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 Class
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 26]
+
+RFC 6137 NTTDM February 2011
+
+
+3.2.7.4. NETWORK_NODE
+
+ +--------------+
+ | NETWORK_NODE |
+ +--------------+
+ | DESCRIPTION | The NOC network node related to the incident.
+ | TYPE | List.
+ | VALID FORMAT | String.
+ | MANDATORY | No.
+ +--------------+
+
+ Figure 35. Network_Node Class
+
+3.2.7.5. NETWORK_LINK_CIRCUIT
+
+ +----------------------+
+ | 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 Class
+
+3.2.7.6. END_LINE_LOCATION_A
+
+ +---------------------+
+ | END_LINE_LOCATION_A |
+ +---------------------+
+ | DESCRIPTION | A-end of the link.
+ | TYPE | Multiple.
+ | VALID FORMAT | String.
+ | MANDATORY | No.
+ +---------------------+
+
+ Figure 37. End_Line_Location_A Class
+
+
+
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 27]
+
+RFC 6137 NTTDM February 2011
+
+
+3.2.7.7. END_LINE_LOCATION_B
+
+ +---------------------+
+ | 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
+
+3.2.8.1. OPEN_ENGINEER
+
+ +---------------+
+ | 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
+
+ +-------------------+
+ | CONTACT_ENGINEERS |
+ +-------------------+
+ | DESCRIPTION | The engineers responsible for the incident
+ | | settlement.
+ | TYPE | List.
+ | VALID FORMAT | String.
+ | MANDATORY | No.
+ +-------------------+
+
+ Figure 40. Contact_Engineers Class
+
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 28]
+
+RFC 6137 NTTDM February 2011
+
+
+3.2.8.3. CLOSE_ENGINEER
+
+ +----------------+
+ | 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
+
+3.2.9.1. HASH
+
+ +-------------+
+ | HASH |
+ +-------------+
+ | DESCRIPTION | Encrypted message hash.
+ | TYPE | Defined.
+ | VALID FORMAT| String.
+ | MANDATORY | No.
+ +-------------+
+
+ Figure 42. Hash Class
+
+3.3. NTTDM Representation
+
+ The collected and processed TTs received from multiple
+ telecommunications networks are adjusted in a normalized NTTDM.
+ Figure 43 shows the representation of this normalized data model.
+ The "DESCRIPTION" attribute is implied.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 29]
+
+RFC 6137 NTTDM February 2011
+
+
+ +------------------------+--------+------------------+---------+
+ | 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
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 30]
+
+RFC 6137 NTTDM February 2011
+
+
+4. Internationalization Issues
+
+ Internationalization and localization are of specific concern to the
+ NTTDM, since it is only through collaboration, often across language
+ barriers, that certain incidents can be resolved. The NTTDM supports
+ this goal by depending on XML constructs, and through explicit design
+ choices in the data model.
+
+ The main advantage of the model is that it provides a normalized data
+ type that is implemented fully in the English language and can be
+ used conveniently. It also supports free-formed text that can be
+ written in any language. In the future, it will provide translation
+ services for all such free-formed text.
+
+5. Example
+
+5.1. Link Failure
+
+ In this section, an example of network TTs exchanged using the
+ proposed format is provided. This is an actual GRNet ticket
+ normalized according to the NTTDM. Fields that were not included in
+ the ticket are left blank.
+
+ <?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>
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 31]
+
+RFC 6137 NTTDM February 2011
+
+
+ <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
+
+ This section provides a sample XML Schema of the NTTDM.
+
+ <?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>
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 32]
+
+RFC 6137 NTTDM February 2011
+
+
+ <!--
+ ===============================================================
+ == 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>
+
+
+
+
+Zisiadis, et al. Experimental [Page 33]
+
+RFC 6137 NTTDM February 2011
+
+
+ <xs:attribute name="lang" type="xs:language"/>
+ </xs:complexType>
+ </xs:element>
+
+ <!--
+ ===============================================================
+ == Partner_ID Class ==
+ ===============================================================
+ -->
+ <xs:element name="Partner_ID" type="nttdm:string_no_underscore"/>
+
+ <!--
+ ===============================================================
+ == 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"/>
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 34]
+
+RFC 6137 NTTDM February 2011
+
+
+ <!--
+ ===============================================================
+ == 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"/>
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 35]
+
+RFC 6137 NTTDM February 2011
+
+
+ <!--
+ ===============================================================
+ == 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"/>
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 36]
+
+RFC 6137 NTTDM February 2011
+
+
+ <!--
+ ===============================================================
+ == 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"/>
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 37]
+
+RFC 6137 NTTDM February 2011
+
+
+ <!--
+ ===============================================================
+ == 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"/>
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 38]
+
+RFC 6137 NTTDM February 2011
+
+
+ <!--
+ ===============================================================
+ == 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"/>
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 39]
+
+RFC 6137 NTTDM February 2011
+
+
+ <!--
+ ===============================================================
+ == 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>
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 40]
+
+RFC 6137 NTTDM February 2011
+
+
+ <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>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 41]
+
+RFC 6137 NTTDM February 2011
+
+
+ <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>
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 42]
+
+RFC 6137 NTTDM February 2011
+
+
+ <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
+
+ The NTTDM data model defines a data model and the relevant XML Schema
+ for trouble ticket normalization; as such, the NTTDM itself does not
+ raise any security concerns. However, some security issues SHOULD be
+ considered as network TTs could carry sensitive information (IP
+ addresses, contact details, authentication details, commercial
+ providers involved, etc.) about flagship institutions (military,
+ health centre...).
+
+ The security considerations MAY involve measures during the exchange
+ as well as during processing of the information.
+
+ The HASH field is intended to provide an integrity insurance
+ attribute within the exchanged tickets; however, it alone does not
+ ensure integrity.
+
+ Confidentiality MAY be ensured by encrypting whole tickets or only
+ some parts of them. This could permit meaningful tickets to be
+ disclosed, while only sensitive information would be protected.
+
+ Peer entity authentication SHOULD be provided in order to establish a
+ session with data origin authentication, regardless of the form in
+ which the TTs are exchanged -- being delivered either through email,
+ web forms, or through a Simple Object Access Protocol (SOAP) service.
+ SOAP is considered the better choice; the model itself, though, 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, and 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 the adoption of the current scheme into the
+ operational procedures of the NOCs. Unauthorized and inappropriate
+ usage MUST be avoided.
+
+
+
+Zisiadis, et al. Experimental [Page 43]
+
+RFC 6137 NTTDM February 2011
+
+
+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:
+
+ o URI: urn:ietf:params:xml:ns:nttdm-1.0
+
+ o Registrant Contact: See the first author listed in the "Authors'
+ Addresses" section of this document.
+
+ o XML: None. Namespace URIs do not represent an XML specification.
+
+ Registration for the NTTDM XML Schema:
+
+ o URI: urn:ietf:params:xml:schema:nttdm-1.0
+
+ o Registrant Contact: See the first author listed in the "Authors'
+ Addresses" section of this document.
+
+ o 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
+ Hellas
+
+ EMail: leandros@uth.gr
+
+
+ Chrysostomos Tziouvaras
+ Greek Research and Technology Network
+ 56, Mesogion Av. 11527, Athens
+ Hellas
+
+ EMail: tziou@grnet.gr
+
+
+ Xavier Jeannin
+ National Centre for Scientific Research
+ Network Unit - UREC
+ France
+
+ EMail: Xavier.Jeannin@urec.cnrs.fr
+
+
+
+
+Zisiadis, et al. Experimental [Page 44]
+
+RFC 6137 NTTDM February 2011
+
+
+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.
+
+
+
+
+Zisiadis, et al. Experimental [Page 45]
+
+RFC 6137 NTTDM February 2011
+
+
+ [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
+ Hellas
+
+ EMail: dzisiadis@iti.gr
+
+
+ Spyros Kopsidas (editor)
+ Centre for Research and Technology Hellas
+ 6th km Thermi-Thessaloniki, 57001
+ Hellas
+
+ EMail: spyros@uth.gr
+
+
+ Matina Tsavli (editor)
+ Centre for Research and Technology Hellas
+ 6th km Thermi-Thessaloniki, 57001
+ Hellas
+
+ EMail: sttsavli@uth.gr
+
+
+ Guillaume Cessieux (editor)
+ Computer Centre of National Institute for
+ Nuclear Physics and Particle Physics (IN2P3-CC)
+ France
+
+ EMail: Guillaume.Cessieux@cc.in2p3.fr
+
+
+
+
+
+
+
+
+
+
+
+Zisiadis, et al. Experimental [Page 46]
+