From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6137.txt | 2579 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2579 insertions(+) create mode 100644 doc/rfc/rfc6137.txt (limited to 'doc/rfc/rfc6137.txt') 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. + + + + + + + 5985 + 01 + 01_5985 + Forth Link Failure + Operational + Closed + 2008-12-16T10:01:15+02:00 + Core Line Fault + Forth Link Failure + Unscheduled + No connectivity + 2008-12-16T09:55:00+02:00 + 2008-12-16T15:00:34+02:00 + HERAKLION + Optical transmitter was changed + 2008-12-16T15:05:00+02:00 + 2008-12-16T15:01:21+02:00 + + + + + +Zisiadis, et al. Experimental [Page 31] + +RFC 6137 NTTDM February 2011 + + + + FORTH + + + FORTH-2 + + Dimitris Zisiadis + Guillaume Cessieux + + Spyros Kopsidas + Chrysostomos Tziouvaras + + High + + + +6. Sample Implementation: XML Schema + + This section provides a sample XML Schema of the NTTDM. + + + + + Trouble Ticket Data Model v-1.0 + + + + + + + + + + + + + + + + + +Zisiadis, et al. Experimental [Page 32] + +RFC 6137 NTTDM February 2011 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zisiadis, et al. Experimental [Page 33] + +RFC 6137 NTTDM February 2011 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zisiadis, et al. Experimental [Page 34] + +RFC 6137 NTTDM February 2011 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zisiadis, et al. Experimental [Page 35] + +RFC 6137 NTTDM February 2011 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zisiadis, et al. Experimental [Page 36] + +RFC 6137 NTTDM February 2011 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zisiadis, et al. Experimental [Page 37] + +RFC 6137 NTTDM February 2011 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zisiadis, et al. Experimental [Page 38] + +RFC 6137 NTTDM February 2011 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zisiadis, et al. Experimental [Page 39] + +RFC 6137 NTTDM February 2011 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zisiadis, et al. Experimental [Page 40] + +RFC 6137 NTTDM February 2011 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zisiadis, et al. Experimental [Page 41] + +RFC 6137 NTTDM February 2011 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zisiadis, et al. Experimental [Page 42] + +RFC 6137 NTTDM February 2011 + + + + + + + + + + + +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, . + + [3] World Wide Web Consortium, "XML Schema Part 0: Primer Second + Edition", W3C Recommendation, 28 October 2004, + . + + [4] World Wide Web Consortium, "XML Schema Part 1: Structures + Second Edition", W3C Recommendation, 28 October 2004, + . + + [5] World Wide Web Consortium, "XML Schema Part 2: Datatypes Second + Edition", W3C Recommendation, 28 October 2004, + . + + [6] World Wide Web Consortium, "Namespaces in XML 1.0 (Third + Edition)", W3C Recommendation, 8 December 2009, + . + + [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] + -- cgit v1.2.3