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