idnits 2.17.1 draft-dzis-nwg-nttdm-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 51 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 624: '...value of this attribute MUST be "1.00"...' RFC 2119 keyword, line 730: '...nd ORIGINAL_ID MUST therefore not...' RFC 2119 keyword, line 1804: '... issues SHOULD be considered as netw...' RFC 2119 keyword, line 1809: '...y considerations MAY involve measures ...' RFC 2119 keyword, line 1814: '... Confidentiality MAY be ensured by enc...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 564 has weird spacing: '...scussed in de...' == Line 730 has weird spacing: '...erefore not...' == Line 731 has weird spacing: '...contain an un...' == Line 884 has weird spacing: '...| The date...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 08, 2010) is 4885 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dimitris Zisiadis 2 Internet-Draft Spyros Kopsidas 3 Intended status: Experimental Track Matina Tsavli 4 Expires: March 20, 2011 Leandros Tassiulas 5 CERTH 6 Chrysostomos Tziouvaras 7 GRNET 8 Guillaume Cessieux 9 Xavier Jeannin 10 CNRS 11 December 08, 2010 13 The Network Trouble Ticket Data Model 15 draft-dzis-nwg-nttdm-08.txt 17 Status of This Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may contain material 21 from IETF Documents or IETF Contributions published or made publicly 22 available before November 10, 2008. The person(s) controlling the 23 copyright in some of this material may not have granted the IETF 24 Trust the right to allow modifications of such material outside the 25 IETF Standards Process. Without obtaining an adequate license from 26 the person(s) controlling the copyright in such materials, this 27 document may not be modified outside the IETF Standards Process, 28 and derivative works of it may not be created outside the IETF 29 Standards Process, except to format it for publication as an RFC or 30 to translate it into languages other than English. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on March 20, 2011. 50 Copyright and License Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with 60 respect to this document. 62 Abstract 64 Handling multiple sets of network trouble tickets (TTs) 65 originating from different participants inter-connected network 66 environments poses a series of challenges for the involved 67 institutions, Grid is a good example of such multi-domain project. 68 Each of the participants follows different procedures for handling 69 trouble in its domain, according to the local technical and 70 linguistic profile. The TT systems of the participants collect, 71 represent and disseminate TT information in different formats. 72 As a result, management of the daily workload by a central Network 73 Operations Centre (NOC) is a challenge on its own. Normalization 74 of TTs to a common format at the central NOC can ease presentation, 75 storing and handling of the TTs. In the present document we provide 76 a model for automating the collection and normalization of the TT 77 received by multiple networks forming the Grid. Each of the 78 participants is using its home TT system within its domain for 79 handling trouble incidents, whereas the central NOC is gathering 80 the tickets in the normalized format for repository and handling. 81 XML is used as the common representation language. The model was 82 defined and used as part of the networking support activity of 83 the EGEE project (Enabling Grids for E-sciencE). 85 Table of Contents 87 1. Introduction .................................................. 5 88 1.1. Terminology ................................................ 6 89 1.2. Notations .................................................. 6 90 1.3. About the Network Trouble Ticket Data Model ................ 6 91 1.4. About the Network Trouble Ticket Implementation ............ 7 92 1.5. Future plans ............................................... 7 94 2. NTTDM Types and Definitions ................................... 8 95 2.1 Types and Definitions for the TYPE Attributes ............... 8 96 2.1.1 Defined ................................................. 8 97 2.1.2 Free .................................................... 8 98 2.1.3 Multiple ................................................ 8 99 2.1.4 List .................................................... 8 100 2.2 Types and Definitions for the VALID FORMAT Attributes ....... 9 101 2.2.1 Predefined String ....................................... 9 102 2.2.1.1 Definitions of the Predefined Values ................10 103 2.2.2 String ................................................. 13 104 2.2.3 Datetime ............................................... 14 105 3. NTTDM ........................................................ 14 106 3.1 NTTDM components ........................................... 14 107 3.1.1 NTTDM Attributes ....................................... 14 108 3.2 NTTDM Aggregate classes ................................... 15 109 3.2.1 NTTDM-Document class ................................... 15 110 3.2.2 Ticket class ........................................... 15 111 3.2.3 Ticket origin information .............................. 17 112 3.2.3.1 PARTNER_ID ......................................... 17 113 3.2.3.2 ORIGINAL_ID ........................................ 17 114 3.2.4 Ticket information ..................................... 17 115 3.2.4.1 TT_ID .............................................. 18 116 3.2.4.2 TT_TITLE ........................................... 18 117 3.2.4.3 TT_TYPE ............................................ 18 118 3.2.4.4 TT_PRIORITY ........................................ 19 119 3.2.4.5 TT_STATUS .......................................... 19 120 3.2.4.6 TT_SOURCE .......................................... 19 121 3.2.4.7 TT_OPEN_DATETIME ................................... 20 122 3.2.4.8 TT_CLOSE_DATETIME .................................. 20 123 3.2.5 Trouble details ........................................ 20 124 3.2.5.1 TT_SHORT_DESCRIPTION ............................... 20 125 3.2.5.2 TT_LONG_DESCRIPTION ................................ 21 126 3.2.5.3 TYPE ............................................... 21 127 3.2.5.4 TT_IMPACT_ASSESSMENT ............................... 21 128 3.2.5.5 START_DATETIME ..................................... 22 129 3.2.5.6 DETECT_DATETIME .................................... 22 130 3.2.5.7 REPORT_DATETIME .................................... 22 131 3.2.5.8 END_DATETIME ....................................... 23 132 3.2.5.9 TT_LAST_UPDATE_TIME ................................ 23 133 3.2.5.10 TIME_WINDOW_START ................................. 23 134 3.2.5.11 TIME_WINDOW_END ................................... 24 135 3.2.5.12 WORK_PLAN_START_DATETIME .......................... 24 136 3.2.5.13 WORK_PLAN_END_DATETIME ............................ 24 137 3.2.6 Related data ........................................... 25 138 3.2.6.1 RELATED_EXTERNAL_TICKETS ........................... 25 139 3.2.6.2 ADDITIONAL_DATA .................................... 25 140 3.2.6.3 RELATED_ACTIVITY ................................... 25 141 3.2.6.4 HISTORY ............................................ 26 142 3.2.7 Localization and impact ................................ 26 143 3.2.7.1 AFFECTED_COMMUNITY ................................. 26 144 3.2.7.2 AFFECTED_SERVICE ................................... 26 145 3.2.7.3 LOCATION ........................................... 27 146 3.2.7.4 NETWORK_NODE ....................................... 27 147 3.2.7.5 NETWORK_LINK_CIRCUIT ............................... 27 148 3.2.7.6 END_LINE_LOCATION_A ................................ 28 149 3.2.7.7 END_LINE_LOCATION_B ................................ 28 150 3.2.8 Contact information .................................... 28 151 3.2.8.1 OPEN_ENGINEER ...................................... 28 152 3.2.8.2 CONTACT_ENGINEERS .................................. 29 153 3.2.8.3 CLOSE_ENGINEER ..................................... 29 154 3.2.9 Security ............................................... 29 155 3.2.9.1 HASH ............................................... 29 156 3.3 NTTDM Representation ....................................... 30 157 4. Internationalization Issues .................................. 32 158 5. Example ...................................................... 32 159 5.1 Link Failure ............................................... 32 160 6. Sample Implementation: XML Schema ............................ 33 161 7. Security Considerations ...................................... 45 162 8. IANA Considerations ........................................... 46 163 9. Acknowledgements ............................................. 47 164 10. List of Acronyms ............................................ 48 165 11. References .................................................. 49 166 11.1 Normative References ...................................... 49 167 11.2 Informative References .................................... 49 168 12. Authors' Addresses .......................................... 50 170 1. Introduction 172 Problem impact assessment, reporting identification and handling 173 as well as trouble information dissemination and delegation of 174 authority are some of the main tasks that have to be implemented 175 by the members of a Grid, for succession in managing the network 176 and maintaining operational efficiency of the services offered to its 177 users. 178 Different TT systems are used by each network domain, delivering TTs 179 in alternate formats, while TT load is growing proportionally with 180 the network size and the serviced users. 181 Hereby we define a data model for TT normalization initially 182 targeted for networking providers serving EGEE [7]. The model is 183 designed in accordance with RFC 1297 [10], meeting requirements 184 of the multiple TT systems used. 185 It is both effective and comprehensive, as it compensates for 186 the core activities of the NOCs. It is also dynamic, allowing 187 additional options to be included in the future, according to demand. 188 It provides an XML representation for conveying incident information 189 across administrative domains between parties that have an 190 operational responsibility of remediation or a watch-and-warning over 191 a defined constituency. 192 The data model encodes information about hosts, networks, and the 193 services running on these systems; attack methodology and associated 194 forensic evidence; impact of the activity; and limited approaches for 195 documenting workflow. 196 The Network Trouble Ticket Data Model (NTTDM) aims to simplify 197 TT exchange within the boundaries of a Grid and to enhance the 198 functional cooperation of every Network operation Centre (NOC) 199 and the Grid Operation Centre (GOC). Community adoption of the 200 NTTDM enhances trouble resolution within the grid framework 201 and imparts network status cognizance by modeling collaboration 202 and information exchange among the operators. The NTTDM definition 203 provides: 205 o A common format that allows GOC as well as all participating 206 NOCs to store, exchange, manage and analyze TTs (assessment 207 of TT impact). 209 o Increased automation in handling a TT since the network 210 operators have a common view to the trouble. 212 The model was designed and used as part of the networking 213 support activity of the EGEE project, as part of the ENOC (EGEE 214 Network Operating Centre) [8] procedures for managing the Grid. 216 1.1. Terminology 218 NTTDM uses specific keywords to describe the various data 219 components. These keywords are: 220 Defined, Free, Multiple, List, Predefined String, String, 221 Datetime, Solved, Cancelled, Inactive, Superseded, 222 Opened/Closed, Operational, Informational, Administrative, 223 Test. 225 Those in this document are to be interpreted as described in 226 Section 2. 228 1.2. Notations 230 The NTTDM is specified in two ways, as an abstract data model 231 and as an XML Schema. Section 3 provides a Unified Modeling 232 Language (UML) [9] model describing the individual classes and 233 their relationship with each other. The semantics of each 234 class are discussed and their attributes explained. In Section 235 6, this UML model is converted in an XML Schema [1, 2, 3, 4]. 236 A specific namespace [5] is also defined. 238 The term "XML document" refers to any instance of an XML 239 Document. The term "NTTDM document" refers to specific 240 elements and attributes of the NTTDM schema. Finally, the 241 terms "class", and "element" will be used interchangeably to 242 reference either a given UML class in the data model or its 243 corresponding schema implementation. 245 1.3. About the Network Trouble Ticket Data Model 247 The NTTDM is a data representation that provides a framework 248 for normalizing and sharing information among network operators 249 and the GOC regarding troubles within the Grid boundaries. 250 There has been a lot of thought processing during the design of 251 the data model: 253 o The data model serves as a common storage and exchange format. 255 o Every NOC still uses its home TT system for network management 256 within its area of control. 258 o As there is no universally adopted definition for a trouble, 259 in the NTTDM definition the term is used with a comprehensive 260 meaning to cover all NOCs. 262 o Handling every possible definition of a trouble incident 263 would call for an extremely expanded and complex data model. 264 Therefore, the NTTDM purpose is to serve as the basis to 265 normalize and exchange TTs. It is flexible and expressive in 266 order to ensure that specific NOC requirements are met. 267 Specific NOC information is kept outside the NTTDM and 268 external databases can be used to feed it. 270 o The domain of managing the information is not fully 271 standardized and must rely on free-form textual descriptions. 272 The NTTDM attempts to strike a balance between supporting 273 this free-form content, while still allowing automated 274 processing of incident information. 276 The NTTDM is only one of feasible TT data representations. The 277 goal of this design was to be as effective and comprehensive to 278 cover for the management of a general grid environment. The 279 already used TT formats influenced the design of the NTTDM. 281 1.4. About the Network Trouble Ticket Implementation 283 Here we describe an example of typical use case. 284 The Grid project EGEE manages its infrastructure as network 285 overlay over the European NRENs and want to be able to warn 286 EGEE sites of the unavailability of the network. Thanks to 287 collaboration with its network provider the EGEE NOC receive 288 TTs (800 tickets/month, 2500 emails/month) from 20 NRENs and 289 should be able to cope with the heavy TT process. Thanks to 290 the NTTDM the EGEE NOC can automate the TT workflow: 292 o TT is filtered, sorted and stored in local DB. 294 o TT impact on the Grid is assessed. 296 o TT is pushed to dashboard and other tools (EGEE TT system, 297 statistics, etc.) 299 1.5. Future plans 301 Since this is an Experimental document, operational experience will 302 be used to expand the sections under 'Ticket Origin Information?. 303 The current specification is already used within EGEE. Other Grids 304 are free to use it and report comments to the authors. After enough 305 experimentation it will be placed on the Standards Track. 307 2. NTTDM Types and Definitions 309 The various data elements of the TT data model are typed. This 310 section discusses these data types. When possible, native Schema 311 data types were adopted, but for more complicated formats, regular 312 expressions or external standards were used. 314 2.1 Types and Definitions for the TYPE attribute. 316 These types are used to describe the TYPE attribute. 318 2.1.1 Defined 320 The Defined data type means that the data model provides a mean 321 to compute this value from the rest of the fields. 323 The Defined data type is implemented as a "Defined" in the 324 schema. 326 2.1.2 Free 328 The Free data type means that the value can be freely chosen. 330 All Free string should have as an attribute the language used. 332 The Free data type is implemented as a "Free" in the schema. 334 2.1.3 Multiple 336 The Multiple data type consists of one value among multiple 337 fixed values. 339 The Multiple data type is implemented as an "Multiple" in the 340 schema. 342 2.1.4 List 344 List means many values among multiple fixed values. 345 The List data type is implemented as a "List" in the schema. 347 2.2 Types and Definitions for the VALID FORMAT attributes 349 2.2.1 Predefined String 351 A Predefined String means the different values are predefined 352 in the data model. 354 Each field that requires a Predefined String contains a specific 355 value. Here is the table that shows the allowed values for such 356 fields. 358 +------------------------+-----------------------------------+ 359 | FIELD NAME | VALUES | 360 +------------------------+-----------------------------------+ 361 | TT_TYPE | Operational, Informational, | 362 | | Administrative, Test | 363 +------------------------+-----------------------------------+ 364 | TYPE | Scheduled, Unscheduled | 365 +------------------------+-----------------------------------+ 366 | TT_PRIORITY | Low, Medium, High | 367 +------------------------+-----------------------------------+ 368 | TT_SHORT_DESCRIPTION | Core Line Fault, Access Line | 369 | | Fault, Degraded Service, Router | 370 | | Hardware Fault, Router Software | 371 | | Fault, Routing Problem, Undefined | 372 | | Problem, Network congestion, | 373 | | Client Upgrade, IPv6, QoS, VoIP, | 374 | | Other | 375 +------------------------+-----------------------------------+ 376 | TT_IMPACT_ASSESSMENT | No impact, Reduced redundancy, | 377 | | Minor performance impact, Severe | 378 | | performance impact, | 379 | | No connectivity, On backup, | 380 | | At risk, Unknown | 381 +------------------------+-----------------------------------+ 382 | TT_STATUS | Opened, Updated, Closed, Solved, | 383 | | Inactive, Cancelled, Reopened, | 384 | | Superseded, Opened/Closed | 385 +------------------------+-----------------------------------+ 386 | TT_SOURCE | Users, Monitoring, Other NOC | 387 +------------------------+-----------------------------------+ 389 Figure 1: The allowed Predefined String values 391 The Predefined String data type is implemented as an "xs:string" in 392 the schema with a sequence of enumerations for the allowed values. 394 2.2.1.1 Definitions of the Predefined Values 396 TT_TYPE 398 o Operational: for network incident & maintenance only. 400 o Informational: Information about the TT system or the 401 exchange interface (maintenance, upgrade). 403 o Administrative: Information about the access to the TTS 404 (credentials) or the exchange interface. 406 o Test: to test the TT system or the exchange interface, etc. 408 TYPE 410 o Scheduled: the incident was scheduled to happen. 412 o Unscheduled: the incident was unscheduled. 414 TT_PRIORITY 416 o Low: the TT priority is low. 418 o Medium: the TT priority is medium. 420 o High: the TT priority is high. 422 TT_SHORT_DESCRIPTION 424 o Core Line Fault: malfunction of a high bandwidth Core line. 426 o Access Line Fault: malfunction of a medium bandwidth Access 427 line. 429 o Degraded Service. 431 o Router Hardware Fault: malfunction of the router hardware. 433 o Router Software Fault: malfunction of the router software. 435 o Routing Problem: incident regarding the routing service. 437 o Undefined Problem: the nature of the problem is not 438 identified. 440 o Network congestion: problem due to traffic at the network 441 (blocked). 443 o Client Upgrade: incidents regarding clients/services upgrade. 445 o IPv6: incident regarding the IPv6 network. 447 o QoS: incident regarding the QoS of the network. 449 o VoIP: incident regarding VoIP. 451 o Other: non listed incident. 453 TT_IMPACT_ASSESSMENT 455 o No impact: the incident does not cause any impacts. 457 o Reduced redundancy: the incident produces reduction at the 458 redundancy. 460 o Minor performance impact: the incident causes a minor 461 performance impact. 463 o Severe performance impact: the incident causes a severe 464 performance impact. 466 o No connectivity: the incident causes failure of connectivity. 468 o On backup: the incident produces malfunction on backup services. 470 o At risk: the incident should not have any impact but possibly 471 it may cause some trouble. 473 o Unknown: the nature of the impact is not identified. 475 TT_STATUS 477 o Opened: the ticket is opened. 479 o Closed: the ticket is closed. 481 o Updated: the ticket's contents have been updated. 483 o Cancelled: the ticket has been opened twice, one of the both 484 tickets is cancelled and a relation is done between them via 485 RELATED_ACTIVITY. 487 o Solved: the incident is solved but the team prefers to 488 monitor for check. 490 o Opened/closed: stands for tickets that are opened only to 491 report an incident that is already solved. 493 o Inactive: the ticket is under the responsibility of an 494 external domain and is no more under the domain control. 496 o Reopened: the ticket was closed by error, or the problem 497 was faulty declared solved. Historical data are very important 498 at this case. 500 o Superseded: the ticket has been superseded by another one 501 (case of a bigger problem having raised many tickets and 502 being merged in one single incident). The RELATED_ACTIVITY 503 field should include the master ticket reference. 505 Allowed transitions for TT_STATUS are only those following. 506 Possible final states are indicated with (X). 508 +------------------+ 509 | Opened/Closed (X)| 510 +------------------+ 511 | 512 | 513 V 514 +--------------+ 515 /-----------------------| Reopened |<-------------------\ 516 | | |----------\ | 517 | +--------------+ | | 518 | ^ | | 519 | | | | 520 | V | | 521 | +-------------------+ | | 522 | | Superseded (X) | | | 523 | | or Inactive (X) | | | 524 | /----------------->| or Cancelled (X) |<---\ | | 525 | | +-------------------+ | | | 526 | | ^ | | | 527 | | | | V | 528 | | +--------+ | +--------+ | 529 | | /---------| Opened |----/ | Solved |-----\ | 530 | | | | |---------------->| | | | 531 | | | +--------+ +--------+ | | 532 | | | | ^ | | 533 V | V | | | | 534 +---------+ | | | | 535 | |----------(|)-------------------------/ V V 536 | Updated | | +------------+ 537 | |----------(|)---------------------------->| | 538 +---------+ | | Closed (X) | 539 \----------------------------->| | 540 +------------+ 542 Figure 2: TT_STATUS transition diagram 544 2.2.2 String 546 The String value is defined by the user of the model. 547 The String data type is implemented as an "xs:string" in the 548 schema. 550 2.2.3 Datetime 552 Date-time strings are represented by the Datetime data type. 553 Each date-time string identifies a particular instant in time; 554 ranges are not supported. 555 Date-time strings are formatted according to a subset of ISO 556 8601: 2000 documented in RFC 3339. 558 The Datetime data type is implemented as an "xs:dateTime" in 559 the schema. 561 3. NTTDM 563 In this section, the individual components of NTTDM will be 564 discussed in detail. This class provides a standardized 565 representation for commonly exchanged Field Name data. 567 3.1 NTTDM Components 569 3.1.1 NTTDM Attributes 571 The Field Name class has four attributes. Each attribute 572 provides information about a Field Name instance. The 573 attributes that characterize one instance constitute all the 574 information required to form the data model. 576 DESCRIPTION 578 This field contains a short description of the field name. 580 TYPE 582 The TYPE attribute contains information about the type of the field 583 name it depends on. The values that it may contain are: 584 Defined, Free, Multiple, List. 586 VALID FORMAT 588 This attribute contains information about the format of each field. 589 The values that it may contain are: Predefined String, String, 590 Datetime. 592 MANDATORY 594 This attribute indicates if the information of each field is 595 required or is optional. In case the information is required 596 the field MANDATORY contains the word: "YES". On the 597 contrary, when filling the information is optional, the 598 field MANDATORY contains the word "NO". 600 3.2 NTTDM Aggregate Classes 602 3.2.1 NTTDM-Document class 604 The NTTDM-Document class is the top-level class in NTTDM. All 605 NTTDM documents are an instance of this class. 607 +---------------+ 608 | NTTDM-Document| 609 +---------------+ 610 | version |<>--{1..*}--[ Ticket ] 611 | lang | 612 +---------------+ 614 Figure 3: NTTDM-Document class 616 The aggregate class that constitutes NTTDM-Document is: 618 Ticket 619 One or more. The information related to a single ticket. 621 The NTTDM-Document class has two attributes: 623 version 624 STRING. The value of this attribute MUST be "1.00" 626 lang 627 Required. 629 3.2.2 Ticket class 631 Every ticket is represented by an instance of the Ticket class. 632 This class provides a standardized representation for commonly 633 exchanged TT data. 635 +---------+ 636 | Ticket | 637 +---------+ 638 | lang |<>----------[ Partner_ID ] 639 | |<>----------[ Original_ID ] 640 | |<>----------[ TT_ID ] 641 | |<>----------[ TT_Title ] 642 | |<>----------[ TT_Type ] 643 | |<>--{0..1}--[ TT_Priority ] 644 | |<>----------[ TT_Status ] 645 | |<>--{0..1}--[ TT_Source ] 646 | |<>----------[ TT_Open_Datetime ] 647 | |<>----------[ TT_Close_Datetime ] 648 | |<>----------[ TT_Short_Description ] 649 | |<>----------[ TT_Long_Description ] 650 | |<>----------[ Type ] 651 | |<>----------[ TT_Impact_Assessment ] 652 | |<>----------[ Start_Datetime ] 653 | |<>--{0..1}--[ Detect_Datetime ] 654 | |<>--{0..1}--[ Report_Datetime ] 655 | |<>----------[ End_Datetime ] 656 | |<>----------[ TT_Last_Update_Time ] 657 | |<>--{0..1}--[ Time_Window_Start ] 658 | |<>--{0..1}--[ Time_Window_End ] 659 | |<>--{0..1}--[ Work_Plan_Start_Datetime ] 660 | |<>--{0..1}--[ Work_Plan_End_Datetime ] 661 | |<>--{0..1}--[ Related_External_Tickets ] 662 | |<>--{0..1}--[ Additional_Data ] 663 | |<>--{0..1}--[ Related_Activity ] 664 | |<>----------[ History ] 665 | |<>--{0..1}--[ Affected_Community ] 666 | |<>--{0..1}--[ Affected_Service ] 667 | |<>----------[ Location ] 668 | |<>--{0..1}--[ Network_Node ] 669 | |<>--{0..1}--[ Network_Link_Circuit ] 670 | |<>--{0..1}--[ End_Line_Location_A ] 671 | |<>--{0..1}--[ End_Line_Location_B ] 672 | |<>--{0..1}--[ Open_Engineer ] 673 | |<>--{0..1}--[ Contact_Engineers ] 674 | |<>--{0..1}--[ Close_Engineer ] 675 | |<>--{0..1}--[ Hash ] 676 +---------+ 678 Figure 4: the Ticket class 680 lang 681 Required. 683 The Field Names are the Aggregate Classes that constitute the 684 NTTDM and each of them is an element that is characterized by a 685 quadruple (DESCRIPTION, TYPE, VALID FORMAT, MANDATORY). 687 3.2.3 Ticket origin information 689 3.2.3.1 PARTNER_ID 691 +--------------+ 692 | PARTNER_ID | 693 +--------------+ 694 | DESCRIPTION | The unique ID of the TT source partner. 695 | TYPE | Multiple. 696 | VALID FORMAT | String. 697 | MANDATORY | Yes. 698 +--------------+ 700 Figure 5: Partner_ID Class 702 3.2.3.2 ORIGINAL_ID 704 +--------------+ 705 | ORIGINAL_ID | 706 +--------------+ 707 | DESCRIPTION | TT ID that was assigned by the party. 708 | TYPE | Free. 709 | VALID FORMAT | String. 710 | MANDATORY | Yes. 711 +--------------+ 713 Figure 6: Original_ID Class 715 3.2.4 Ticket information 716 3.2.4.1 TT_ID 718 +--------------+ 719 | TT_ID | 720 +--------------+ 721 | DESCRIPTION | The unique ID of the TT. 722 | TYPE | As defined below. 723 | VALID FORMAT | String. 724 | MANDATORY | Yes. 725 +--------------+ 727 Figure 7: TT_ID Class 729 TYPE is constructed as "PARTNER_ID"_"ORIGINAL_ID". 730 PARTNER_ID and ORIGINAL_ID MUST therefore not 731 contain an underscore character. 733 3.2.4.2 TT_TITLE 735 +---------------+ 736 | TT_TITLE | 737 +---------------+ 738 | DESCRIPTION | The title of the TT. 739 | TYPE | DEFINED. 740 | VALID FORMAT | String. 741 | MANDATORY | Yes. 742 +---------------+ 744 Figure 8: TT_Title Class 746 3.2.4.3 TT_TYPE 748 +---------------+ 749 | TT_TYPE | 750 +---------------+ 751 | DESCRIPTION | The type of the TT. 752 | TYPE | Multiple. 753 | VALID FORMAT | Predefined String. 754 | MANDATORY | Yes 755 +---------------+ 757 Figure 9: Type Class 759 3.2.4.4 TT_PRIORITY 761 +--------------+ 762 | TT_PRIORITY | 763 +--------------+ 764 | DESCRIPTION | The TT priority. 765 | TYPE | Multiple. 766 | VALID FORMAT | Predefined String. 767 | MANDATORY | No. 768 +--------------+ 770 Figure 10: TT_Priority Class 772 3.2.4.5 TT_STATUS 774 +--------------+ 775 | TT_STATUS | 776 +--------------+ 777 | DESCRIPTION | The TT status. 778 | TYPE | Multiple. 779 | VALID FORMAT | Predefined String. 780 | MANDATORY | Yes. 781 +--------------+ 783 Figure 11: TT_Status Class 785 3.2.4.6 TT_SOURCE 787 +--------------+ 788 | TT_SOURCE | 789 +--------------+ 790 | DESCRIPTION | The source of the ticket. 791 | TYPE | Multiple. 792 | VALID FORMAT | Predefined String. 793 | MANDATORY | No. 794 +--------------+ 796 Figure 12: TT_Source Class 798 3.2.4.7 TT_OPEN_DATETIME 800 +------------------+ 801 | TT_OPEN_DATETIME | 802 +------------------+ 803 | DESCRIPTION | The datetime when the TT was opened. 804 | TYPE | Multiple. 805 | VALID FORMAT | Datetime. 806 | MANDATORY | Yes. 807 +------------------+ 809 Figure 13: TT_Open_Datetime Class 811 3.2.4.8 TT_CLOSE_DATETIME 813 +-------------------+ 814 | TT_CLOSE_DATETIME | 815 +-------------------+ 816 | DESCRIPTION | The datetime when the TT was closed. 817 | TYPE | Multiple. 818 | VALID FORMAT | Datetime. 819 | MANDATORY | Yes. 820 +-------------------+ 822 Figure 14: TT_Close_Datetime Class 824 3.2.5 Trouble details 826 3.2.5.1 TT_SHORT_DESCRIPTION 828 +----------------------+ 829 | TT_SHORT_DESCRIPTION | 830 +----------------------+ 831 | DESCRIPTION | The short description of the trouble. 832 | TYPE | Multiple. 833 | VALID FORMAT | Predefined String. 834 | MANDATORY | Yes. 835 +----------------------+ 837 Figure 15: TT_Short_Description Class 839 3.2.5.2 TT_LONG_DESCRIPTION 841 +---------------------+ 842 | TT_LONG_DESCRIPTION | 843 +---------------------+ 844 | DESCRIPTION | The detailed description of the 845 | | incident/maintenance reported in the TT. 846 | TYPE | Free. 847 | VALID FORMAT | String. 848 | MANDATORY | Yes. 849 +---------------------+ 851 Figure 16: TT_Long_Description Class 853 3.2.5.3 TYPE 855 +--------------+ 856 | TYPE | 857 +--------------+ 858 | DESCRIPTION | The type of the trouble. 859 | TYPE | Multiple. 860 | VALID FORMAT | Predefined String. 861 | MANDATORY | Yes. 862 +--------------+ 864 Figure 17: Type Class 866 3.2.5.4 TT_IMPACT_ASSESSMENT 868 +----------------------+ 869 | TT_IMPACT_ASSESSMENT | 870 +----------------------+ 871 | DESCRIPTION | The impact of the incident/maintenance. 872 | TYPE | Multiple. 873 | VALID FORMAT | Predefined String. 874 | MANDATORY | Yes. 875 +----------------------+ 877 Figure 18: TT_Impact_Assessement Class 879 3.2.5.5 START_DATETIME 881 +----------------+ 882 | START_DATETIME | 883 +----------------+ 884 | DESCRIPTION | The datetime that the 885 | | incident/maintenance started. 886 | TYPE | Multiple. 887 | VALID FORMAT | Datetime. 888 | MANDATORY | Yes. 889 +----------------+ 891 Figure 19: Start_Datetime Class 893 3.2.5.6 DETECT_DATETIME 895 +-------------------+ 896 | DETECT_DATETIME | 897 +-------------------+ 898 | DESCRIPTION | The datetime when the incident was detected. 899 | TYPE | Multiple. 900 | VALID FORMAT | Datetime. 901 | MANDATORY | No. 902 +-------------------+ 904 Figure 20: Detect_Datetime Class 906 3.2.5.7 REPORT_DATETIME 908 +-----------------+ 909 | REPORT_DATETIME | 910 +-----------------+ 911 | DESCRIPTION | The datetime when the incident was reported. 912 | TYPE | Multiple. 913 | VALID FORMAT | Datetime. 914 | MANDATORY | No. 915 +-----------------+ 917 Figure 21: Report_Datetime Class 919 3.2.5.8 END_DATETIME 921 +--------------+ 922 | END_DATETIME | 923 +--------------+ 924 | DESCRIPTION | The datetime when the incident/maintenance ended. 925 | TYPE | Multiple. 926 | VALID FORMAT | Datetime. 927 | MANDATORY | Yes. 928 +--------------+ 930 Figure 22: End_Datetime Class 932 3.2.5.9 TT_LAST_UPDATE_TIME 934 +---------------------+ 935 | TT_LAST_UPDATE_TIME | 936 +---------------------+ 937 | DESCRIPTION | The last datetime when the TT was updated. 938 | TYPE | Multiple. 939 | VALID FORMAT | Datetime. 940 | MANDATORY | Yes. 941 +---------------------+ 943 Figure 23: TT_Last_Update_Time Class 945 3.2.5.10 TIME_WINDOW_START 947 +-------------------+ 948 | TIME_WINDOW_START | 949 +-------------------+ 950 | DESCRIPTION | The window start time in which planned 951 | | maintenance may occur. 952 | TYPE | Multiple. 953 | VALID FORMAT | Datetime. 954 | MANDATORY | No, unless TYPE is "Scheduled". 955 +-------------------+ 957 Figure 24: Time_Window_Start Class 959 3.2.5.11 TIME_WINDOW_END 961 +-----------------+ 962 | TIME_WINDOW_END | 963 +-----------------+ 964 | DESCRIPTION | The window end time in which planned 965 | | maintenance may occur. 966 | TYPE | Multiple. 967 | VALID FORMAT | Datetime. 968 | MANDATORY | No, unless TYPE is "Scheduled". 969 +-----------------+ 971 Figure 25: Time_Window_End Class 973 3.2.5.12 WORK_PLAN_START_DATETIME 975 +--------------------------+ 976 | WORK_PLAN_START_DATETIME | 977 +--------------------------+ 978 | DESCRIPTION | Work planned (expected) start time 979 | | in case of maintenance. 980 | TYPE | Multiple. 981 | VALID FORMAT | Datetime. 982 | MANDATORY | No. 983 +--------------------------+ 985 Figure 26: Work_Plan_Start_Datetime Class 987 3.2.5.13 WORK_PLAN_END_DATETIME 989 +------------------------+ 990 | WORK_PLAN_END_DATETIME | 991 +------------------------+ 992 | DESCRIPTION | Work planned (expected) end time in case 993 | | of maintenance. 994 | TYPE | Multiple. 995 | VALID FORMAT | Datetime. 996 | MANDATORY | No. 997 +------------------------+ 999 Figure 27: Work_Plan_End_Datetime Class 1001 The period delimited by WORK_PLAN_START_DATETIME and 1002 WORK_PLAN_END_DATETIME must be included in the period delimited 1003 by TIME_WINDOW_START and TIME_WINDOW_END, duplicated with 1004 {START, END}_DATETIME, even in case of maintenance. 1006 3.2.6 Related data 1008 3.2.6.1 RELATED_EXTERNAL_TICKETS 1010 +--------------------------+ 1011 | RELATED_EXTERNAL_TICKETS | 1012 +--------------------------+ 1013 | DESCRIPTION | The NOC entity related to the incident. 1014 | TYPE | List. 1015 | VALID FORMAT | String. 1016 | MANDATORY | No. 1017 +--------------------------+ 1019 Figure 28: Related_External_Tickets Class 1021 3.2.6.2 ADDITIONAL_DATA 1023 +-----------------+ 1024 | ADDITIONAL_DATA | 1025 +-----------------+ 1026 | DESCRIPTION | Additional information. 1027 | TYPE | Free. 1028 | VALID FORMAT | String. 1029 | MANDATORY | No. 1030 +-----------------+ 1032 Figure 29: Additional_Data Class 1034 3.2.6.3 RELATED_ACTIVITY 1036 +------------------+ 1037 | RELATED_ACTIVITY | 1038 +------------------+ 1039 | DESCRIPTION | The trouble TT IDs of the related incidents. 1040 | TYPE | Multiple. 1041 | VALID FORMAT | String. 1042 | MANDATORY | No. 1043 +------------------+ 1045 Figure 30: Related_Activity Class 1047 3.2.6.4 HISTORY 1049 +--------------+ 1050 | HISTORY | 1051 +--------------+ 1052 | DESCRIPTION | The necessary Actions/events log. 1053 | TYPE | Free. 1054 | VALID FORMAT | String. 1055 | MANDATORY | Yes. 1056 +--------------+ 1058 Figure 31: History Class 1060 Note: This field must NOT be empty when the VALID FORMAT attribute of 1061 the TT_STATUS field is different from "OPENED" or "OPENED/CLOSED". 1063 3.2.7 Localization and Impact 1065 3.2.7.1 AFFECTED_COMMUNITY 1067 +--------------------+ 1068 | AFFECTED_COMMUNITY | 1069 +--------------------+ 1070 | DESCRIPTION | Information about the community that was 1071 | | affected by the incident. 1072 | TYPE | Free. 1073 | VALID FORMAT | String. 1074 | MANDATORY | No. 1075 +--------------------+ 1077 Figure 32: Affected_Community Class 1079 3.2.7.2 AFFECTED_SERVICE 1081 +------------------+ 1082 | AFFECTED_SERVICE | 1083 +------------------+ 1084 | DESCRIPTION | The service that was affected by the incident. 1085 | TYPE | Multiple. 1086 | VALID FORMAT | String. 1087 | MANDATORY | No. 1088 +------------------+ 1090 Figure 33: Affected_Service Class 1092 3.2.7.3 LOCATION 1094 +--------------+ 1095 | LOCATION | 1096 +--------------+ 1097 | DESCRIPTION | Location (Pop site, city, etc) of the 1098 | | incident/maintenance. 1099 | TYPE | Multiple. 1100 | VALID FORMAT | String. 1101 | MANDATORY | Yes. 1102 +--------------+ 1104 Figure 34: Location Class 1106 3.2.7.4 NETWORK_NODE 1108 +--------------+ 1109 | NETWORK_NODE | 1110 +--------------+ 1111 | DESCRIPTION | The NOC network node related to the incident. 1112 | TYPE | List. 1113 | VALID FORMAT | String. 1114 | MANDATORY | No. 1115 +--------------+ 1117 Figure 35: Network_Node Class 1119 3.2.7.5 NETWORK_LINK_CIRCUIT 1121 +----------------------+ 1122 | NETWORK_LINK_CIRCUIT | 1123 +----------------------+ 1124 | DESCRIPTION | Name of the network line related to the 1125 | | incident. 1126 | TYPE | List. 1127 | VALID FORMAT | String. 1128 | MANDATORY | No. 1129 +----------------------+ 1131 Figure 36: Network_Link_Circuit Class 1133 3.2.7.6 END_LINE_LOCATION_A 1135 +---------------------+ 1136 | END_LINE_LOCATION_A | 1137 +---------------------+ 1138 | DESCRIPTION | A-end of the link. 1139 | TYPE | Multiple. 1140 | VALID FORMAT | String. 1141 | MANDATORY | No. 1142 +---------------------+ 1144 Figure 37: End_Line_Location_A Class 1146 3.2.7.7 END_LINE_LOCATION_B 1148 +---------------------+ 1149 | END_LINE_LOCATION_B | 1150 +---------------------+ 1151 | DESCRIPTION | B-end of the link. 1152 | TYPE | Multiple. 1153 | VALID FORMAT | String. 1154 | MANDATORY | No. 1155 +---------------------+ 1157 Figure 38: End_Line_Location_B Class 1159 3.2.8 Contact information 1161 3.2.8.1 OPEN_ENGINEER 1163 +---------------+ 1164 | OPEN_ENGINEER | 1165 +---------------+ 1166 | DESCRIPTION | The engineer that opened the ticket. 1167 | TYPE | Multiple. 1168 | VALID FORMAT | String. 1169 | MANDATORY | No. 1170 +---------------+ 1172 Figure 39: Open_Engineer Class 1174 3.2.8.2 CONTACT_ENGINEERS 1176 +-------------------+ 1177 | CONTACT_ENGINEERS | 1178 +-------------------+ 1179 | DESCRIPTION | The engineers responsible for the incident 1180 | | settlement. 1181 | TYPE | List. 1182 | VALID FORMAT | String. 1183 | MANDATORY | No. 1184 +-------------------+ 1186 Figure 40: Contact_Engineers Class 1188 3.2.8.3 CLOSE_ENGINEER 1190 +----------------+ 1191 | CLOSE_ENGINEER | 1192 +----------------+ 1193 | DESCRIPTION | The engineer that closed the ticket. 1194 | TYPE | Multiple. 1195 | VALID FORMAT | String. 1196 | MANDATORY | No. 1197 +----------------+ 1199 Figure 41: Close_Engineer Class 1201 3.2.9 Security 1203 3.2.9.1 HASH 1205 +-------------+ 1206 | HASH | 1207 +-------------+ 1208 | DESCRIPTION | Encrypted message hash. 1209 | TYPE | DEFINED. 1210 | VALID FORMAT| String. 1211 | MANDATORY | No. 1212 +-------------+ 1214 Figure 42: Hash Class 1216 3.3 NTTDM Representation 1218 The collected and processed TTs received from multiple 1219 telecommunications networks are adjusted in a normalized NTTDM. 1220 Below, there is the representation of this normalized Data Model. 1221 The "DESCRIPTION" attribute is implied. 1223 +------------------------+--------+------------------+---------+ 1224 | FIELD NAME | TYPE |VALID FORMAT |MANDATORY| 1225 +------------------------+--------+------------------+---------+ 1226 |PARTNER_ID |MULTIPLE|STRING |YES | 1227 |ORIGINAL_ID |FREE |STRING |YES | 1228 |TT_ID |DEFINED |STRING |YES | 1229 |TT_TITLE |DEFINED |STRING |YES | 1230 |TT_TYPE |MULTIPLE|PREDEFINED STRING |YES | 1231 |TT_PRIORITY |MULTIPLE|PREDEFINED STRING |NO | 1232 |TT_STATUS |MULTIPLE|PREDEFINED STRING |YES | 1233 |TT_SOURCE |MULTIPLE|STRING |NO | 1234 |TT_OPEN_DATETIME |MULTIPLE|DATETIME |YES | 1235 |TT_CLOSE_DATETIME |MULTIPLE|DATETIME |YES | 1236 |TT_SHORT_DESCRIPTION |MULTIPLE|PREDEFINED STRING |YES | 1237 |TT_LONG_DESCRIPTION |FREE |STRING |NO | 1238 |TYPE |MULTIPLE|PREDEFINED STRING |YES | 1239 |TT_IMPACT_ASSESSMENT |MULTIPLE|PREDEFINED STRING |YES | 1240 |START_DATETIME |MULTIPLE|DATETIME |YES | 1241 |DETECT_DATETIME |MULTIPLE|DATETIME |NO | 1242 |REPORT_DATETIME |MULTIPLE|DATETIME |NO | 1243 |END_DATETIME |MULTIPLE|DATETIME |YES | 1244 |TT_LAST_UPDATE_TIME |MULTIPLE|DATETIME |YES | 1245 |TIME_WINDOW_START |MULTIPLE|DATETIME |NO | 1246 |TIME_WINDOW_END |MULTIPLE|DATETIME |NO | 1247 |WORK_PLAN_START_DATETIME|MULTIPLE|DATETIME |NO | 1248 |WORK_PLAN_END_DATETIME |MULTIPLE|DATETIME |NO | 1249 |RELATED_EXTERNAL_TICKETS|LIST |STRING |NO | 1250 |ADDITIONAL_DATA |FREE |STRING |NO | 1251 |RELATED_ACTIVITY |MULTIPLE|STRING |NO | 1252 |HISTORY |FREE |STRING |YES | 1253 |AFFECTED_COMMUNITY |FREE |STRING |NO | 1254 |AFFECTED_SERVICE |MULTIPLE|STRING |NO | 1255 |LOCATION |MULTIPLE|STRING |YES | 1256 |NETWORK_NODE |LIST |STRING |NO | 1257 |NETWORK_LINK_CIRCUIT |LIST |STRING |NO | 1258 |END_LINE_LOCATION_A |MULTIPLE|STRING |NO | 1259 |END_LINE_LOCATION_B |MULTIPLE|STRING |NO | 1260 |OPEN_ENGINEER |MULTIPLE|STRING |NO | 1261 |CONTACT_ENGINEERS |LIST |STRING |NO | 1262 |CLOSE_ENGINEER |MULTIPLE|STRING |NO | 1263 |HASH |DEFINED |STRING |NO | 1264 +------------------------+--------+------------------+---------+ 1266 Figure 43: the Field Name class 1268 4. Internationalization Issues 1270 Internationalization and localization is of specific concern to 1271 the NTTDM, since it is only through collaboration, often across 1272 language barriers, that certain incidents be resolved. The 1273 NTTDM supports this goal by depending on XML constructs, and 1274 through explicit design choices in the data model. 1275 The main advantage of the model is that it provides a 1276 normalized data type that is implemented fully in the English 1277 language and can be used conveniently. It also supports Free 1278 formed text that can be written in any language. In the future 1279 it will provide translation services for all the free-formed 1280 text. 1282 5. Example 1284 5.1 Link Failure 1286 In this section an example is provided of network TTs exchanged 1287 using the proposed format. This is an actual GRNet ticket 1288 normalized according to TTDM. Fields that were not included in 1289 the ticket are left blank. 1291 1292 1293 1295 1296 5985 1297 01 1298 01_5985 1299 Forth Link Failure 1300 Operational 1301 Closed 1302 2008-12-16T10:01:15+02:00 1303 Core Line Fault 1304 Forth Link Failure 1305 Unscheduled 1306 No connectivity 1307 2008-12-16T09:55:00+02:00 1308 2008-12-16T15:00:34+02:00 1309 HERAKLION 1310 Optical transmitter was changed 1311 2008-12-16T15:05:00+02:00 1312 2008-12-16T15:01:21+02:00 1313 1314 FORTH 1315 1316 1317 FORTH-2 1318 1319 Dimitris Zisiadis 1320 Guillaume Cessieux 1321 1322 Spyros Kopsidas 1323 Chrysostomos Tziouvaras 1324 1325 High 1326 1327 1329 6. Sample implementation: XML schema 1331 This section provides a sample XML Schema of the NTTDM. 1333 1334 1340 1341 Trouble Ticket Data Model v-1.0 1343 1345 1350 1351 1352 1353 1354 1355 1356 1358 1359 1361 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1412 1417 1419 1424 1426 1431 1433 1438 1440 1445 1446 1451 1453 1458 1460 1465 1467 1472 1474 1479 1481 1486 1489 1494 1496 1501 1503 1508 1511 1516 1518 1523 1525 1530 1531 1536 1538 1543 1545 1550 1552 1557 1559 1564 1566 1571 1572 1577 1580 1585 1587 1592 1595 1600 1602 1607 1609 1614 1615 1620 1622 1627 1629 1634 1637 1642 1644 1649 1651 1656 1657 1662 1664 1669 1671 1676 1678 1683 1684 1685 1686 1687 1689 1690 1691 1693 1694 1696 1697 1698 1700 1701 1702 1703 1704 1706 1707 1709 1710 1711 1713 1714 1716 1717 1718 1720 1721 1723 1724 1725 1726 1727 1728 1729 1730 1732 1733 1734 1735 1736 1737 1739 1740 1741 1742 1743 1744 1745 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1790 1791 1792 1793 1794 1795 1796 1797 1799 7. Security Considerations 1801 The NTTDM data model defines a data model and the relevant XML 1802 schema for trouble ticket normalization; as such, NTTDM itself 1803 does not raise any security concerns. However, some security 1804 issues SHOULD be considered as network TTs could carry sensitive 1805 information (IP addresses, contact details, authentication details, 1806 commercial providers involved etc.) about flagship institutions 1807 (military, health centre...). 1809 The security considerations MAY involve measures during the exchange 1810 as well as during processing of the information. 1811 The HASH field is intended to provide an integrity insurance 1812 attribute within the exchanged tickets, however it does not ensure 1813 integrity alone. 1814 Confidentiality MAY be ensured by encrypting whole tickets or only 1815 some parts. This could allow having meaningful tickets to be 1816 disclosed while only sensitive information protected. 1817 Peer entity authentication SHOULD be provided in order to establish 1818 session with data origin authentication regardless of the form in 1819 which the TTs are exchanged, being either delivered through email, 1820 web forms or through a SOAP service. The latter is considered the 1821 better choice, the model itself though does not specify the 1822 communications requirements. 1823 The underlying communications service MUST provide guarantees to 1824 properly address integrity, confidentiality and peer entity 1825 authentication. The selection of the enforcing mechanisms is not in 1826 the scope of this document and the choice is up to the implementers. 1828 For data processing security each participating organization MAY 1829 use its own privacy policy, as part of its own data processing 1830 system. This approach avoids any interoperability issues and does not 1831 pose any extra burden for the adoption of the current scheme into the 1832 operational procedures of the NOCs. Unauthorized and inappropriate 1833 usage MUST be avoided. 1835 8. IANA Considerations 1837 This document uses URNs to describe an XML namespace and schema 1838 conforming to a registry mechanism described in [6]. 1840 Registration for the NTTDM namespace: 1842 o URI: urn:ietf:params:xml:ns:nttdm-1.0 1843 o Registrant Contact: See the first author of the "Author's 1844 Address" section of this document. 1845 o XML: None. Namespace URIs do not represent an XML 1846 specification. 1848 Registration for the NTTDM XML schema: 1850 o URI: urn:ietf:params:xml:schema:nttdm-1.0 1851 o Registrant Contact: See the first author of the "Author's 1852 Address" section of this document. 1853 o XML: See the XML Schema in Section 6 of this document. 1855 9. Acknowledgements 1857 The following groups and individuals contributed substantially 1858 to this document and are gratefully acknowledged: 1860 - Rodwell Toby, Apted Emma, DANTE 1862 - Allocchio Claudio, Vuagnin Gloria, Battista Claudia, GARR 1864 - Schauerhammer Karin, Stoy Robert, DFN 1866 10. List of acronyms 1868 TT: Trouble Ticket 1870 NTTDM: Network Trouble Ticket Data Model 1872 DB: Data Base 1874 EGEE: Enabling Grid for E-sciencE 1876 ENOC: EGEE NOC 1878 NOC: Network Operation Centre 1880 GOC: Grid Operation Centre 1882 NREN: National Research and Educational Networks 1884 QoS: Quality of service 1886 UML: Unified Modeling Language 1888 XML: Extensible Markup Language 1890 11. References 1892 11.1 Normative References 1894 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0 1895 (Fifth Edition)", W3C Recommendation, 26 November 2008, 1896 . 1898 [2] World Wide Web Consortium, XML Schema Part 0: Primer Second 1899 Edition, W3C Recommendation, 28 October 2004. 1900 1902 [3] World Wide Web Consortium, "XML XML Schema Part 1: 1903 Structures Second Edition", W3C Recommendation, October 2004, 1904 . 1906 [4] World Wide Web Consortium, "XML Schema Part 2: Datatypes 1907 Second Edition", W3C Recommendation, October 2004, 1908 . 1910 [5] World Wide Web Consortium, "Namespaces in XML 1.0 (Third 1911 Edition)", W3C Recommendation, 8 December 2009, 1912 . 1914 [6] Mealling, M., "The IETF XML Registry", RFC 3688, January 1915 2004. 1917 11.2 Informative References 1919 [7] http://www.eu-egee.org/ 1921 [8] http://egee-sa2.web.cern.ch/egee-sa2/ENOC.html 1923 [9] Rumbaugh, J., Jacobson, I., and G. Booch, "The Unified 1924 Modeling Language Reference Model," ISBN 020130998X, 1925 Addison-Wesley, 1998. 1927 [10] Johnson, D., "NOC Internal Integrated Trouble Ticket System 1928 Functional Specification Wishlist ("NOC TT Requirements")", 1929 RFC 1297, January 1992. 1931 12. Authors' Addresses 1933 Dimitris Zisiadis 1934 Centre for Research and Technology 1935 6th km Thermi-Thessaloniki, 57001 1936 Hellas 1938 Email: dzisiadis@iti.gr 1940 Spyros Kopsidas 1941 Centre for Research and Technology 1942 6th km Thermi-Thessaloniki, 57001 1943 Hellas 1945 Email: spyros@uth.gr 1947 Matina Tsavli 1948 Centre for Research and Technology 1949 6th km Thermi-Thessaloniki, 57001 1950 Hellas 1952 Email: sttsavli@uth.gr 1954 Leandros Tassiulas 1955 Centre for Research and Technology 1956 6th km Thermi-Thessaloniki, 57001 1957 Hellas 1959 Email: leandros@uth.gr 1961 Chrysostomos Tziouvaras 1962 Greek Research and Technology Network 1963 56, Mesogion Av. 11527, Athens 1964 Hellas 1966 Email: tziou@grnet.gr 1967 Guillaume Cessieux 1968 Computer Centre of National Institute for Nuclear Physics and 1969 Particle 1970 Physics (IN2P3-CC) - France 1972 Email: Guillaume.Cessieux@cc.in2p3.fr 1974 Xavier Jeannin 1975 National Centre for Scientific Research 1976 Network Unit - UREC - France 1978 Email: Xavier.Jeannin@urec.cnrs.fr