    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]