idnits 2.17.1 draft-betts-netmod-framework-data-schema-uml-04.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 25, 2016) is 2740 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 451 == Unused Reference: 'RFC3444' is defined on line 598, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netmod Working Group M. Betts, Ed. 3 Internet-Draft ZTE 4 Intended status: Informational N. Davis, Ed. 5 Expires: April 28, 2017 Ciena 6 K. Lam, Ed. 7 E. Varma, Ed. 8 Nokia 9 B. Zeuner, Ed. 10 Deutsche Telekom 11 S. Mansfield, Ed. 12 Ericsson 13 P. Doolan, Ed. 14 Coriant 15 October 25, 2016 17 Framework for Deriving Interface Data Schema from UML Information Models 18 draft-betts-netmod-framework-data-schema-uml-04 20 Abstract 22 This draft describes a framework for how purpose and protocol 23 specific interfaces can be systematically derived from an underlying 24 common information model, focusing upon the networking and forwarding 25 domain. The benefit of using such an approach in interface 26 specification development is to promote convergence, 27 interoperability, and efficiency. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 28, 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 2. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Information Modeling . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Unified Modeling Language . . . . . . . . . . . . . . . . 5 68 3.2. Standard UML Information Model . . . . . . . . . . . . . 5 69 4. From UML IM to Data Schema Definition . . . . . . . . . . . . 7 70 4.1. Methodology Overview . . . . . . . . . . . . . . . . . . 7 71 4.2. Common Information Model . . . . . . . . . . . . . . . . 8 72 4.2.1. Core Model . . . . . . . . . . . . . . . . . . . . . 9 73 4.2.2. Technology specific or application specific Sub- 74 models . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.3. Common Information Model View for a Specific Purpose . . 9 76 4.4. Data Schema . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.5. Interface encoding . . . . . . . . . . . . . . . . . . . 12 78 5. Translation from UML . . . . . . . . . . . . . . . . . . . . 12 79 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 86 11.2. Informative References . . . . . . . . . . . . . . . . . 13 87 Appendix A. Additional Material . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 Interface specifications are often generated as point solutions where 93 the designer codes a particular interface from domain (problem space) 94 concepts that may not be explicitly captured, may be defined using 95 localized terminology that is subject to ambiguity in interpretation, 96 and is highly focused on a particular use-case/application. The 97 designer typically provides a representation of the interface schema 98 in the form of a data schema [RFC3444](i.e., data structures conveyed 99 over the interface), which only exposes the view of the domain 100 relevant at that specific interface. As this data schema is a simple 101 statement of the particular interface, it solely describes 102 relationships relevant to the specific realization, having no 103 inherent relationship to other interfaces in the system. 105 Approaching the development of interface specifications on a per use- 106 case/application basis tends to promote unnecessary variety through a 107 proliferation of similar interfaces, resulting in unnecessary 108 divergences that limit interoperability. It also risks confusion of 109 representational artifacts with fundamental characteristics of the 110 information to be conveyed across the interface. There is also a 111 risk that conflicting representations of the same information may be 112 generated. Finally, as each such interface appears to stand alone, 113 it thereby fails to capture relationships with other aspects of the 114 same (or different) domains that are not explicitly needed for the 115 interface. 117 This draft describes a framework for how a protocol specific data 118 schema and the encoding used for the interface can be systematically 119 derived from an underlying common information model, focusing upon 120 the networking and forwarding domain. The benefit of using such an 121 approach in the development of interface specifications is to promote 122 convergence, interoperability, and efficiency. 124 1.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 2. Basic Concepts 132 An information model condenses domain knowledge and insights to 133 provide a representation of its essential concepts, structures, and 134 inter-relationships. In capturing domain understanding, such a model 135 offers a coherent and consistent terminology and structure, expresses 136 the semantics of the domain, and interrelates all relevant aspects of 137 the domain. It enables a consistent expression of information that 138 improves interoperability between software components at interfaces 139 derived from it. A "good" information model should capture domain 140 best practices, and be designed to support domain variety as well as 141 extensibility and evolution. Examples of domains include networking 142 and forwarding, storage, etc. A common industry information model is 143 the assembly of all domain information models, which inter-relate at 144 "touch points". Note that a common industry information model should 145 not be interpreted as being a monolithic entity; in particular, a 146 modular structure is essential to allow for extensibility. 148 There may be several relevant views of any particular domain, 149 depending upon the perspective of the viewer, all of which are 150 interrelated and involve subsets of the information model, and none 151 of which contradict each other. (It should be noted that one view 152 provides the information model representation of the overall domain.) 153 To form a particular (purpose-specific) view, some elements of the 154 model may be pruned. Additionally, for efficiency, some systematic 155 refactoring of the information model may also occur. 157 In this draft, the term data schema is used in the context of either: 158 (i) a specific protocol that is used to implement a purpose specific 159 interface, or (ii) a programming language that is used to invoke a 160 purpose specific API. Note that it is possible to map directly from 161 the purpose specific information model to interface encoding. 163 While a purpose specific interface/API is not a simple direct 164 encoding of the information model of the overall domain, it is by its 165 nature based on a relevant view of the information model of the 166 domain (i.e., a purpose specific information model view). It must be 167 completely and consistently traceable to this view and should use the 168 associated domain terminology. Depending on its application, a 169 particular view may lead to a number of encoded forms at various 170 types of interfaces/APIs. The information model does not dictate the 171 encoded form, which will depend upon such factors as necessary 172 capability, interaction style, and programming language. 174 3. Information Modeling 176 This section introduces the Unified Modeling Language (UML), which 177 has been used to model application structure, behavior, and 178 architecture (in addition to business process and data structure). 179 It also provides references to existing and ongoing work on standard 180 information models based on UML. 182 3.1. Unified Modeling Language 184 The information model is expressed in terms of the Unified Modeling 185 Language (UML) [OMG_UML], which was developed by the Object 186 Management Group. It is a general-purpose modeling language in the 187 field of software engineering. In 2000 the Unified Modeling Language 188 was also accepted by the International Organization for 189 Standardization (ISO) as an approved ISO standard [ISO_IEC_UML]. UML 190 may be used in four ways: 192 o To define a set of objects (instantiated classes that, if 193 organized, describe a data model) 195 o As an information model 197 o As a metamodel (used to create an information model) 199 o As a meta-metamodel 201 UML defines a number of basic model elements (UML artifacts), such as 202 object classes, attributes, associations, interfaces, operations, 203 operation parameters, data types, etc. In order to assure a 204 consistent and harmonized modelling approach, and to ensure 205 uniformity in the application of UML to a problem domain, a subset of 206 the basic model artifacts should be selected according to guidelines 207 for creating an information model expressed in UML [ONF_TR-514]. The 208 guidelines are generic; i.e., they are not specific to any particular 209 domain that the information model is addressing, nor are they 210 restricted to any particular protocol interface data schema. A UML 211 information model may be created using Open Source UML tools; 212 guidelines to be taken into account during the creation of a UML 213 information model for the Open Source tool Papyrus have been 214 developed in [ONF_TR-515]. 216 3.2. Standard UML Information Model 218 Information models expressed in UML, primarily focused upon the 219 networking and forwarding domain, have been, and are in the process 220 of being, developed in ITU-T, TM Forum, NGMN, 3GPP, MEF, ONF, and 221 others. 223 ONF has defined the Core Model of the ONF Common Information Model 224 (ONF-CIM). The ONF Core Model [ONF_TR-512] provides a representation 225 of network resources for the purpose of management-control and is 226 independent of specific forwarding technology. The Core Model can be 227 augmented to provide forwarding technology specific representation. 229 ITU-T Recommendations are focused on understanding the 230 telecommunications problem space and developing information models 231 addressing network and network element considerations. Some examples 232 of available standard ITU-T information models relevant to the 233 networking and forwarding domain include: 235 o ITU-T G.874.1 (2016), Optical transport network: Protocol-neutral 236 management information model for the network element view 237 [ITU-T_G.874.1] 239 o ITU-T G.8052/Y.1346 (2016), Protocol-neutral management 240 information model for the Ethernet Transport capable network 241 element [ITU-T_G.8052] 243 o ITU-T G.8152/Y.1375 (2016), Protocol-neutral management 244 information model for the MPLS-TP network element [ITU-T_G.8152] 246 o ITU-T G.7711/Y.1702 (2016), Generic protocol-neutral management 247 Information Model for transport resources [ITU-T_G.7711] 249 Note that ONF and ITU-T have adopted the same Core Model in 250 [ONF_TR-512] and [ITU-T_G.7711], and are continuing to maintain 251 alignment. 253 The above information models are developed from ITU-T Recommendations 254 that define the respective transport technology functional models and 255 management requirements. 257 The TM Forum community has likewise developed extensive models of the 258 same space from the network level management perspective [TMF_MTNM] 259 [TMF_MTOSI] [TMF_TR225]. The basis for all functions made available 260 to the network level management is defined in the protocol-neutral 261 network element level management work done in ITU-T. Its models thus 262 complement the ITU-T information models. In further collaboration 263 with 3GPP, considerable joint effort has been devoted to develop a 264 consistent and coherent approach to that space. Most recently 265 (September 2016), a Collaboration Agreement was signed between the 266 MEF Forum, ONF, and TM Forum to enable common model collaboration on 267 Information Model constructs and network resource Information Model. 269 The NGMN has published a document called Next Generation Converged 270 Operations Requirements (NGCOR) [NGMN_NGCOR], with the expressed 271 purpose of taking these requirements into account when converged 272 management interfaces for mobile and fixed networks are being 273 standardized in the SDOs. An ongoing collaboration called the Multi- 274 SDO Project on Converged Management is taking care that the 275 requirements are considered during the specification of new 276 interfaces. It includes participants from ETSI, NGMN, TMF, 3GPP, and 277 other SDOs, equipment vendors, OS vendors and service providers. 279 4. From UML IM to Data Schema Definition 281 This section outlines the overall structure of a modular and 282 evolvable common information model and how purpose specific IM views 283 and data schema may be derived from it [ONF_TR-513]. 285 4.1. Methodology Overview 287 As illustrated in Figure 1 below, the common information model is 288 comprised of a library of model artifacts (objects, attributes, and 289 associations) organized into a number of sub-models, to facilitate 290 the independent development of technology and application specific 291 extensions. The Core Model refers to information model artifacts 292 that are intended for use by multiple applications and/or forwarding 293 technologies. For purposes of navigability, the Core Model is 294 further sub-structured into Core Network Model (CNM), Core Foundation 295 Model, Core Physical Model, and the Core Specification Model (these 296 are further discussed in Section 4.2.1). The forwarding technology 297 specific model refers to technology specific extensions; e.g., for 298 OTN, Ethernet, MPLS-TP, SDH, etc. The application specific model 299 refers to extensions for supporting particular applications. 301 +-------------+ 302 | Common | 303 | Information | 304 | Model | 305 | (CIM) | 306 |+-----------+| 307 ||Core Model || 308 ||(TR-512) || 309 ||* CNM || 310 ||* Foundat. || 311 ||* Physical || 312 ||* ... || 313 ||* ... || +----------+ +---------+ +---------+ 314 |+-----------+| | | Map |Interface| Map |Interface| 315 |+-----------+| | View |---+\| 1 data |---+\| 1 | 316 ||Technology ||-------\ | of |---+/| schema |---+/|encoding | 317 ||specific ||Prune/ \| CIM | +---------+ +---------+ 318 ||models ||refactor/| for a | 319 |+-----------+|-------/ |particular| Map +---------+ 320 |+-----------+| . | purpose |-------------------+\|Interface| 321 ||Compute || . | |-------------------+/| 2 | 322 ||specific ||-------\ +----------+| . . |encoding | 323 ||models ||Prune/ \ +--.--.----+| . . +---------+ 324 |+-----------+|refactor/ +-.--.-----+|. . 325 | . |-------/ . . . . 326 | . | . . . . . 327 | . | . . . . . 328 |+-----------+| . . . . . 329 ||Storage ||. . . . . . 330 ||specific || . . . . . . 331 ||models || . .. . . . 332 |+-----------+| . . . . . 333 | | . .. . . . 334 +-------------+ . . .. . . 335 . . . . . . . 336 . . . . .. . . 337 . . . . . . . . 338 +-----------.-----.-----.------.--.---------------.---.------------ 339 |Guidelines . . . . . . . . \ 340 |+----------\ +------\ +------\ +----------\ +------------ | 341 || TR-513 \ |TR-514 \ |TR-515 \ | TR-513 \ +------------\\ | 342 || Model | |Use of | |Papyrus| | Common | | Interfac ||| 343 || structure | |UML | |GitHub | | process | | specific |+| 344 |+-----------+ +-------+ +-------+ +-----------+ +-------------+ | 345 +------------------------------------------------------------------+ 347 High-level common information model structure and methodology for 348 deriving interface protocol specific data schema/interface encodings 350 Figure 1 352 The following subsections provide further elaboration of the high- 353 level methodology introduced above. 355 4.2. Common Information Model 357 As introduced earlier, a common information model includes the 358 objects/packages, their properties (represented as attributes), and 359 their relationships, etc. that are necessary to describe the domain 360 for the applications being developed. It will be necessary to 361 continually expand and refine the common model over time as new 362 forwarding technologies, capabilities and applications are 363 encompassed and new insights are gained. To allow these extensions 364 to be made in a seamless manner, the common information model is 365 structured into a number of sub-models. This modelling approach 366 enables application specific and forwarding technology specific 367 extensions to be developed by domain experts with appropriate 368 independence. 370 Over time, some part(s) of the common information model may need to 371 be augmented or changed. Any such areas are clearly identified using 372 model lifecycle stereotypes (controlled annotations; e.g., 373 experimental, preliminary, obsolete) to ensure ongoing compatibility 374 and to ease migration. The use of the lifecycle stereotypes is 375 described in the UML modeling guidelines [ONF_TR-514]. 377 4.2.1. Core Model 379 The core model is organized into a number of sub-models, each 380 addressing a specific topic to allow for easier navigation. 381 Currently, these consist of the Core Network Model (CNM), Core 382 Foundation Model, Core Physical Model, and the Core Specification 383 Model [I-D.lam-topology]. 385 o The CNM consists of artifacts that model the essential network 386 aspects that are neutral to the forwarding technology(ies) of the 387 network. The CNM currently encompasses Forwarding, Termination, 388 Topology, and Resilience aspects (subsets of the CNM). 390 o The Core Foundation Model provides a detailed view of all aspects 391 of the CNM that are relevant to all other parts of the Common 392 Information Model. Currently, this model includes coverage of 393 naming and identifiers (so that communications about an entity can 394 take place). 396 o The Core Physical Model provides a view of the model for physical 397 entities (including equipment, holders, and connectors). 399 o The Core Specification Model provides for a machine readable form 400 of specific localized behavior, enables the introduction of run 401 time schema, allows leverage of existing standards definitions 402 (e.g., technology/application specific) in a machine readable 403 language, and simplifies representations. 405 4.2.2. Technology specific or application specific Sub-models 407 These sub-models contain the artifacts (objects, attributes and 408 associations) that relate solely the specific technology or 409 application. In some cases, the addition of an application or 410 technology sub-model will also require, and result in, enhancement of 411 the core model. 413 4.3. Common Information Model View for a Specific Purpose 415 The next step is the development of a purpose specific information 416 model, which is a true subset of the common information model. A 417 purpose specific information model will typically be much smaller 418 than the entire common information model. To provide maximal reuse, 419 the purpose specific view is developed in two steps: (1) prune and 420 refactor a copy of the artifacts of the common information model to 421 provide a model of the network to provide a purpose specific 422 information model of the network to be managed, where only those 423 artefacts that represent the capabilities that are both in scope and 424 supported are included, and (2) define the access rights for the 425 various groups of users that will manage that network. Pruning and 426 refactoring provides a purpose specific information model that 427 represents the capabilities of the network of interest. The 428 definition of access rights provides the ability to limit the actions 429 that can be taken by the various user groups that will use that 430 information model. 432 o Pruning is used to derive a (smaller) model with a narrower scope 433 or view. Pruning can remove the objects/packages/attributes/ 434 associations that are not required. 436 - Select the required object classes from the common IM (all 437 mandatory attributes and packages must be included) 439 - Select the required conditional packages and optional attributes 440 (note that, where appropriate, conditional packages and optional 441 attributes may be declared mandatory in the purpose specific IM) 443 - Remove any optional associations that are not required 445 o Refactoring allows the model to be simplified and made compatible 446 with existing models or terminology. Some guidelines for 447 refactoring include: 449 - Collapsing of classes when reducing multiplicity (e.g., from 450 [1..*] to [1]). When this results in a composition association 451 of multiplicity [1] between a subordinate and superior object 452 class, they can be combined into a single object class by moving 453 the attributes of the superior class into the subordinate class. 455 - Splitting of a class along a view boundary where the two parts 456 are related by a specific multiplicity. 458 - Where beneficial, reducing the depth of the inheritance (i.e., 459 combining object classes by moving the attributes of the super 460 class into the subclass). 462 - Adding reverse navigation, if useful for the purpose. In many 463 places in the common IM, there is only support for navigation 464 from a subordinate object class to a superior object class. 465 This allows new subordinate object classes to be added without 466 any impact on the superior object class. In a purpose specific 467 implementation it is frequently useful to be able to navigate 468 the relationship between superior and subordinate object classes 469 in both directions. 471 - Constraining attribute definitions. This can be done by 472 reducing legal value ranges, defining which (if any) attributes 473 should be read only (for all users), and/or defining constraints 474 between attributes. 476 o Traceability 478 Use the Realization association with a specific stereotype 479 PruneAndRefactor to maintain the traceability from the pruned/ 480 refactored model to the Common IM. 482 4.4. Data Schema 484 A data schema (DS) is developed in the context of either a specific 485 protocol that is used to implement a purpose specific interface or a 486 programming language that is used to invoke a purpose specific API. 487 The DS is constructed by mapping of the purpose specific information 488 model together with the operations patterns from the common 489 information model to provide the interface protocol specific DS that 490 includes operations and notifications. The operations should include 491 data structures taken directly from the purpose specific information 492 model view with no further adjustment. 494 The development of the data schema should consider the following: 496 o The operations should act on the information in a way consistent 497 with the modeled object lifecycle interdependency rules as defined 498 in the common IM. 500 - Instance lifecycle dependencies should ensure sensible interface 501 operation structuring and interface flow rules 503 - Some form of transaction should be used over the interface to 504 account for lifecycle dependencies of the model 506 o The operations should abide by the attribute properties. Read 507 only attributes (except those which are defined as isInvariant) 508 should not be included in data related to creation of an object 509 (e.g., not in createData) or in a specification of a desired 510 object structure outcome. 512 o Usage of attribute value ranges, etc. to allow "effort" statement, 513 optionality and negotiation to be supported by the interface. 515 4.5. Interface encoding 517 This step encodes either a purpose specific data schema or a purpose 518 specific information model into either: (i) a specific protocol that 519 is used to implement a purpose specific interface, or (ii) a 520 programming language that is used to invoke a purpose specific API. 521 If the interface is encoded directly from the purpose specific 522 information model then the interface operations must be added as 523 described above. 525 5. Translation from UML 527 Applying the methodology outlined in Section 4, protocol-specific 528 interface data schema/encodings may be derived from existing, and 529 emerging, standard UML information models addressing the forwarding 530 and networking domains (e.g., [ITU-T_G.7711], G.874.1 531 [ITU-T_G.874.1]). 533 In order to assure a consistent and valid data modelling language 534 representation that enables maximum interoperability, translation 535 guidelines from UML information models to data schema/interface 536 encodings are required. A set of translation rules also assists in 537 development of automated tooling. 539 Guidelines have been developed for translation of data modeled with 540 UML to YANG including mapping of object classes, attributes, data 541 types, associations, interfaces, operations and operation parameters, 542 notifications, and lifecycle [ONF_TR-531], [I-D.mansfield-uml]. 544 It should be noted that the concept of deriving protocol-specific 545 modules from UML information models is not new (e.g., MEF 38 [MEF_38] 546 and MEF 39 [MEF_39] provide YANG modules derived from UML information 547 models G.8052 [ITU-T_G.8052] and MEF 7.1 [MEF_7.1] for Service OAM 548 Fault and Performance Monitoring, respectively.). What is new is the 549 concept of an open, modular, evolvable common information model, 550 coupled with an associated suite of essential guidelines and tooling 551 (e.g., UML, Open Source tooling, translation, etc.), for realizing a 552 coherent set of solution modules. 554 6. Summary 556 This draft describes a modular and scalable approach for 557 systematically deriving purpose and protocol specific interfaces from 558 an underlying common information model, focusing upon the networking 559 and forwarding domain. Building upon an underlying common 560 information modeling description of network resources (functionality, 561 capabilities, flexibility) is a key enabler to convergence and 562 interoperability. It is also future proof in the sense that the 563 emergence of new protocols becomes solely a non-disruptive mapping 564 issue. It should be noted that not all domains require development 565 of information model prior to solutions development; the domains 566 where this is of greatest benefit involve networking domains 567 requiring support for an enhanced level of control and network 568 programmability. 570 7. Acknowledgements 572 8. Contributors 574 Dave Hood 575 Ericsson 576 USA 577 email dave.hood@ericsson.com 579 9. IANA Considerations 581 This memo includes no request to IANA. 583 10. Security Considerations 585 This informational document only describes a framework for deriving 586 interface data schema from UML Information Models. As such, security 587 concerns are out of the scope of this document. 589 11. References 591 11.1. Normative References 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, 595 DOI 10.17487/RFC2119, March 1997, 596 . 598 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 599 Information Models and Data Models", RFC 3444, 600 DOI 10.17487/RFC3444, January 2003, 601 . 603 11.2. Informative References 605 [I-D.lam-topology] 606 Lam, K., Varma, E., Doolan, P., Davis, N., Zeuner, B., 607 Betts, M., Busi, I., and S. Mansfield, "Usage of IM for 608 network topology to support TE Topology YANG Module 609 Development", 2016, . 612 [I-D.mansfield-uml] 613 Mansfield, S., Zeuner, B., Davis, N., Yun, Y., Tochio, Y., 614 Lam, K., and E. Varma, "Guidelines for Translation of UML 615 Information Model to YANG Data Model", 2016, 616 . 619 [ISO_IEC_UML] 620 ISO/IEC, "ISO/IEC 19505-1:2012 - Information technology - 621 Object Management Group Unified Modeling Language (OMG 622 UML) - Part 1: Infrastructure. Iso.org.2012-04-20. 623 Retrieved 2014-04-10", 2012. 625 [ITU-T_G.7711] 626 ITU-T, "ITU-T G.7711/Y.1702 (2016), Generic protocol- 627 neutral management Information Model for transport network 628 resources", 2016. 630 [ITU-T_G.8052] 631 ITU-T, "ITU-T G.8052/Y.1346 (2016), Protocol-neutral 632 management information model for the Ethernet Transport 633 capable network element", 2016, 634 . 636 [ITU-T_G.8152] 637 ITU-T, "ITU-T G.8152/Y.1375 (2016), Protocol-neutral 638 management information model for the MPLS-TP network 639 element", 2016. 641 [ITU-T_G.874.1] 642 ITU-T, "ITU-T G.874.1 (2016), Optical transport network: 643 Protocol-neutral management information model for the 644 network element view", 2016, 645 . 647 [MEF_38] MEF, "Service OAM Fault Management YANG Modules", 2012, . 651 [MEF_39] MEF, "Service OAM Performance Monitoring YANG Module", 652 2012, . 655 [MEF_7.1] MEF, "Carrier Ethernet Management Information Model 656 [superseded by MEF 7.2, which supports additional sets of 657 service attributes defined in recent MEF specifications]", 658 2009, . 661 [NGMN_NGCOR] 662 NGMN Alliance, "Next Generation Converged Operations 663 Requirements (NGCOR)", 2013, 664 . 668 [OMG_UML] OMG, "OMG Unified Modelling Language (UML), 669 Infrastructure, Version 2.4.1", 2011. 671 [ONF_TR-512] 672 ONF, "TR-512 Core Information Model 1.2", 2016, 673 . 677 [ONF_TR-513] 678 ONF, "TR-513 Common Information Model Overview 1.2", 2016, 679 . 683 [ONF_TR-514] 684 ONF, "TR-514 UML Modeling Guidelines 1.2", 2016, 685 . 689 [ONF_TR-515] 690 ONF, "TR-515 Papyrus Guidelines 1.2", 2016, 691 . 695 [ONF_TR-531] 696 ONF, "TR-531 UML to YANG Mapping Guidelines 1.0", 2016, 697 . 701 [TMF_MTNM] 702 TM Forum, "TM Forum Multi Technology Network Management, 703 Release 3.5", 2009, 704 . 707 [TMF_MTOSI] 708 TM Forum, "TM Forum Multi Technology OS Interface, Release 709 3.0", 2012, 710 . 713 [TMF_TR225] 714 TM Forum, "TM Forum TR225, Logical Resource: Network 715 Function Model", 2014. 717 Appendix A. Additional Material 719 TBD 721 Authors' Addresses 723 Malcolm Betts (editor) 724 ZTE 725 Canada 727 Phone: +1 678 534 2542 728 Email: malcolm.betts@zte.com.cn 730 Nigel Davis (editor) 731 Ciena 732 UK 734 Email: ndavis@ciena.com 735 Kam Lam (editor) 736 Nokia 737 USA 739 Phone: +1 732 331 3476 740 Email: kam.lam@nokia.com 742 Eve Varma (editor) 743 Nokia 744 USA 746 Email: eve.varma@nokia.com 748 Bernd Zeuner (editor) 749 Deutsche Telekom 750 Germany 752 Phone: +49 6151 58 12086 753 Email: b.zeuner@telekom.de 755 Scott Mansfield (editor) 756 Ericsson 757 USA 759 Phone: +1 724 931 9316 760 Email: scott.mansfield@ericsson.com 762 Paul Doolan (editor) 763 Coriant 764 Germany 766 Phone: +1 972 357 5822 767 Email: paul.doolan@coriant.com