idnits 2.17.1 draft-ietf-ccamp-l1csm-yang-10.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 date (September 9, 2019) is 1685 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC XXXX' is mentioned on line 276, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'MEF63' == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-layer1-types-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Y. Lee 3 Internet-Draft SKKU 4 Intended status: Standards Track K. Lee 5 Expires: March 12, 2020 Korea Telecom 6 H. Zheng 7 D. Dhody 8 Huawei Technologies 9 O. Gonzalez de Dios 10 Telefonica 11 D. Ceccarelli 12 Ericsson 13 September 9, 2019 15 A YANG Data Model for L1 Connectivity Service Model (L1CSM) 16 draft-ietf-ccamp-l1csm-yang-10 18 Abstract 20 This document provides a YANG data model for Layer 1 Connectivity 21 Service Model (L1CSM). The intent of this document is to provide a 22 Layer 1 service model exploiting YANG data model, which can be 23 utilized by a customer network controller to initiate a service 24 request connectivity as well as retrieving service states toward a 25 Layer 1 network controller communicating with its customer network 26 controller. This YANG model is NMDA-compliant. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 12, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . 3 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 65 1.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6 66 1.4. Prefixes in Data Node Names . . . . . . . . . . . . . . . 6 67 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3. L1CSM YANG Model (Tree Structure) . . . . . . . . . . . . . . 7 69 4. L1CSM YANG Code . . . . . . . . . . . . . . . . . . . . . . . 8 70 5. JSON Example . . . . . . . . . . . . . . . . . . . . . . . . 12 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 74 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 77 10.2. Informative References . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 This document provides a YANG data model for L1VPN Connectivity 83 Service Model (L1CSM) which can be classified as Network Service YANG 84 module per [RFC8199]. The intent of this document is to provide a 85 transport service model exploiting YANG data model, which can be 86 utilized by a client network controller to initiate a service request 87 connectivity request as well as retrieving service states toward a 88 transport network controller communicating with the client controller 89 via a NETCONF [RFC8341] or a RESTCONF [RFC8040] interface. 91 [RFC4847] provides a framework and service level requirements for 92 Layer 1 Virtual Private Networks (L1VPNs). It classifies service 93 models as management-based service model, signaling-based service 94 model (Basic Mode) and signaling and routing service model (Enhanced 95 Mode). 97 In the management-based service model, customer management systems 98 and provider management systems communicate with each other. 99 Customer management systems access provider management systems to 100 request layer 1 connection setup/deletion between a pair of CEs. 101 Customer management systems may obtain additional information, such 102 as resource availability information and monitoring information, from 103 provider management systems. There is no control message exchange 104 between a CE and PE. 106 In the signaling-based service model (Basic Model), the CE-PE 107 interface's functional repertoire is limited to path setup signaling 108 only. In the Signaling and routing service model (Enhanced Mode), 109 the CE-PE interface provides the signaling capabilities as in the 110 Basic Mode, plus permits limited exchange of information between the 111 control planes of the provider and the customer to help such 112 functions as discovery of customer network routing information (i.e., 113 reachability or TE information in remote customer sites), or 114 parameters of the part of the provider's network dedicated to the 115 customer. 117 The primary focus of this document is to describe L1CS YANG model 118 required for the instantiation of point-to-point L1VPN service. A 119 L1VPN is a service offered by a core layer 1 network to provide layer 120 1 connectivity between two or more customer sites where the customer 121 has some control over the establishment and type of the connectivity. 123 The data model presented in Section 3 is in consistent with [MEF63]. 124 The data model includes configuration and state data according to the 125 new Network Management Datastore Architecture [RFC8342]. 127 1.1. Deployment Scenarios 129 Figure 1 depicts a deployment scenario of the L1VPN SDN control-based 130 service model for an external customer instantiating L1 point-to- 131 point connectivity to the provider. 133 +------------+ 134 | Customer | 135 | Service | 136 |Orchestrator| 137 +------------+ 138 | 139 .. .. .. .. ..|.. .. .. .. .. .. 140 : | : 141 : +--------------------+ : 142 : | | : 143 : | +----------+ | : 144 : | | Network | | : 145 : | | SDN | | : 146 : | |Controller| | : 147 : | |/NMS/EMS | | : 148 : | +----------+ | : 149 : | | : 150 : | | : 151 +----+ : +----+ +----+ +----+ : +----+ 152 | CE |----:---| PE |----| P |----| PE |---:---| CE | 153 +----+ : +----+ +----+ +----+ : +----+ 154 : | | : 155 : | | : 156 : +--------------------+ : 157 : | | : 158 : |<-Provider network->| : 160 Customer Customer 161 Interface Interface 163 Figure 1: L1VPN SDN Controller/EMS/NMS-Based Service Model: External 164 Customer 166 With this scenario, the customer service orchestrator interfaces with 167 the network SDN controller of the provider using Customer Service 168 Model as defined in [RFC8309]. 170 Figure 2 depicts another deployment scenario for internal customer 171 (e.g., higher-layer service management department(s)) interfacing the 172 layer 1 transport network department. With this scenario, a multi- 173 service backbone is characterized such that each service department 174 of a provider (e.g., L2/3 services) that receives the same provider's 175 L1VPN service provides a different kind of higher-layer service. The 176 customer receiving the L1VPN service (i.e., each service department) 177 can offer its own services, whose payloads can be any layer (e.g., 178 ATM, IP, TDM). The layer 1 transport network and each service 179 network belong to the same organization, but may be managed 180 separately. The Service SDN Controller is the control/management 181 entity owned by higher-layer service department (e.g., L2/3 VPN) 182 whereas the Network SDN Controller is the control/management entity 183 responsible for Layer 1 connectivity service. The CEs in Figure 2 184 are L2/3 devices that interface with L1 PE devices. 186 +----------+ 187 | Service | 188 | SDN | 189 |Controller| 190 |/EMS/NMS | 191 | for L2/3 | 192 +----------+ 193 | 194 | 195 | 196 +--------------------+ 197 | | 198 | +----------+ | 199 | | Network | | 200 | | SDN | | 201 | |Controller| | 202 | |/EMS/NMS | | 203 | | for L1VPN| | 204 | +----------+ | 205 | | 206 | | 207 +----+ +----+ +----+ +----+ +----+ 208 | CE |--------| PE |----| P |----| PE |------| CE | 209 +----+ +----+ +----+ +----+ +----+ 210 | | | | 211 | | | | 212 | +--------------------+ | 213 | | | | 214 | |<------------------>| | 215 | Provider Network | 216 | For Layer 1 | 217 |<------------------------------------------>| 218 Provider Network for L2/3 220 Figure 2: L1VPN SDN Controller/EMS/NMS-Based Service Model: Internal 221 Customer 223 The benefit is that the same layer 1 transport network resources are 224 shared by multiple services. A large capacity backbone network (data 225 plane) can be built economically by having the resources shared by 226 multiple services usually with flexibility to modify topologies, 227 while separating the control functions for each service department. 228 Thus, each customer can select a specific set of features that are 229 needed to provide their own service [RFC4847]. 231 1.2. Terminology 233 Refer to [RFC4847] and [RFC5253] for the key terms used in this 234 document. 236 The following terms are defined in [RFC7950] and are not redefined 237 here: 239 o client 241 o server 243 o augment 245 o data model 247 o data node 249 The following terms are defined in [RFC6241] and are not redefined 250 here: 252 o configuration data 254 o state data 256 The terminology for describing YANG data models is found in 257 [RFC7950]. 259 1.3. Tree Diagram 261 A simplified graphical representation of the data model is used in 262 Section 3 of this this document. The meaning of the symbols in these 263 diagrams is defined in [RFC8340]. 265 1.4. Prefixes in Data Node Names 267 In this document, names of data nodes and other data model objects 268 are prefixed using the standard prefix associated with the 269 corresponding YANG imported modules. The module ietf-layer1-types 270 specified in [I-D.ietf-ccamp-layer1-types] and ietf-yang-types 271 specified in [RFC6991] are imported in this module. 273 +-------------+-------------------+------------------------------+ 274 | Prefix | YANG module | Reference | 275 +-------------+-------------------+------------------------------+ 276 | l1csm | ietf-l1csm | [RFC XXXX] | 277 | layer1-types|ietf-layer1-types | [I-D.ietf-ccamp-layer1-types]| 278 | yang | ietf-yang-types | [RFC6991] | 279 +-------------+-------------------+------------------------------+ 281 Note: The RFC Editor will replace XXXX with the number assigned to 282 the RFC once this draft becomes an RFC. 284 2. Definitions 286 L1VC Layer 1 Virtual Connection 288 SLS Service Level Specification 290 UNI User Network Interface 292 PE Provider Edge 294 CE Customer Edge 296 EP End Point 298 P Protocol 300 C Coding 302 O Optical Interface 304 3. L1CSM YANG Model (Tree Structure) 305 module: ietf-l1csm 306 +--rw l1-connectivity 307 +--rw access 308 | +--rw unis 309 | +--rw uni* [id] 310 | +--rw id string 311 | +--rw protocol? identityref 312 | +--rw coding? identityref 313 | +--rw optical-interface? identityref 314 +--rw services 315 +--rw service* [service-id] 316 +--rw service-id string 317 +--rw endpoint-1 318 | +--rw id string 319 | +--rw uni -> /l1-connectivity/access/unis/uni/id 320 +--rw endpoint-2 321 | +--rw id string 322 | +--rw uni -> /l1-connectivity/access/unis/uni/id 323 +--rw start-time? yang:date-and-time 324 +--rw time-interval? int32 325 +--rw performance-metric* identityref 327 4. L1CSM YANG Code 329 file "ietf-l1csms@2019-09-09.yang" 330 module ietf-l1csm { 331 yang-version 1.1; 332 namespace "urn:ietf:params:xml:ns:yang:ietf-l1csm"; 333 prefix "l1csm"; 335 import ietf-yang-types { 336 prefix "yang"; 337 } 339 import ietf-layer1-types { 340 prefix "layer1-types"; 341 } 343 organization 344 "Internet Engineering Task Force (IETF) CCAMP WG"; 346 contact 348 "Editor: Y. Lee (younglee_tx@gmail.com) 349 Editor: K. Lee (kwangkoog.lee@kt.com) 350 Editor: H. Zheng (zhenghaomian@huawei.com) 351 Editor: D. Dhody (dhruv.ietf@gmail.com) 352 Editor: O. G. de-Dios (oscar.gonzalezdedios@telefonica.com) 353 Editor: D. Ceccarelli (daniele.ceccarelli@ericsson.com)"; 355 description 356 "This module describes L1 connectivity service based on MEF 63: 357 Subscriber Layer 1 Service Attribute Technical Specification. 358 Refer to MEF 63 for all terms and the original references 359 used in the module. 361 Copyright (c) 2019 IETF Trust and the persons identified as 362 authors of the code. All rights reserved. 363 Redistribution and use in source and binary forms, with or 364 without modification, is permitted pursuant to, and subject 365 to the license terms contained in, the Simplified BSD 366 License set forth in Section 4.c of the IETF Trust's Legal 367 Provisions Relating to IETF Documents 368 (http://trustee.ietf.org/license-info). 370 This version of this YANG module is part of RFC XXXX; see 371 the RFC itself for full legal notices."; 373 revision "2019-09-09" { 374 description "Initial revision."; 375 reference "RFC XXXX: A Yang Data Model for L1 Connectivity 376 Service Model (L1CSM)"; 377 // Note: The RFC Editor will replace XXXX with the number 378 // assigned to the RFC once this draft becomes an RFC. 379 } 381 grouping protocol-coding-optical-interface { 382 description 383 "describes where p:protocol type; c:coding 384 function; o:optical interface function"; 385 reference "MEF 63"; 386 leaf protocol { 387 type identityref { 388 base "layer1-types:client-signal"; 389 } 390 description 391 "List of physical layer L1VC client protocol"; 393 } 394 leaf coding { 395 type identityref { 396 base "layer1-types:coding-func"; 397 } 398 description "coding function"; 399 } 401 leaf optical-interface { 402 type identityref { 403 base "layer1-types:optical-interface-func"; 404 } 405 description "optical-interface-function"; 406 } 408 } 410 grouping subscriber-l1vc-sls-service-attribute { 411 description 412 "The value of the Subscriber L1VC SLS (Service Level 413 Specification) Service Attribute"; 414 reference "MEF 63"; 416 leaf start-time { 417 type yang:date-and-time; 418 description "a time that represent the date and time 419 for the start of the SLS"; 420 } 422 leaf time-interval { 423 type int32; 424 units seconds; 425 description "a time interval (e.g., 2,419,200 seconds 426 which is 28 days) that is used in 427 conjunction wuth time-start to specify a 428 contiguous sequence of time intervals T for 429 determining when performance objectives are 430 met."; 431 } 433 leaf-list performance-metric { 434 type identityref { 435 base "layer1-types:service-performance-metric"; 436 } 437 description "list of service performance metric."; 438 } 440 } 442 grouping subscriber-l1vc-endpoint-attributes { 443 description 444 "subscriber layer 1 connection endpoint attributes"; 445 reference "MEF 63"; 446 container endpoint-1 { 447 description "One end of UNI id's - string and id"; 448 leaf id { 449 type string; 450 mandatory true; 451 description "subscriber end point ID of one end"; 452 } 454 leaf uni { 455 type leafref { 456 path "/l1-connectivity/access/unis/uni/id"; 457 } 458 mandatory true; 459 description "this is one end of subscriber L1VC end point 460 ID value = UNI-1"; 461 } 462 } 463 container endpoint-2 { 464 description "One end of UNI id's - string and id"; 465 leaf id { 466 type string; 467 mandatory true; 468 description "subscriber end point ID of the other end"; 469 } 471 leaf uni { 472 type leafref { 473 path "/l1-connectivity/access/unis/uni/id"; 474 } 475 mandatory true; 476 description 477 "this is one other end of subscriber L1VC end point 478 ID value = UNI-2"; 479 } 480 } 481 } 483 container l1-connectivity { 484 description 485 "serves as a top-level container for a list of layer 1 486 connection services (l1cs)"; 488 container access { 489 description "UNI configurations for access networks"; 491 container unis { 492 description "the list of UNI's to be configured"; 493 list uni { 494 key "id"; 495 description "UNI identifier"; 496 leaf id { 497 type string; 498 description "the UNI id of UNI Service Attributes"; 499 } 501 uses protocol-coding-optical-interface; 502 } 503 } 504 } 506 container services { 507 description "L1VC services"; 508 list service { 509 key "service-id"; 510 description 511 "an unique identifier of a subscriber L1VC service"; 513 leaf service-id { 514 type string; 515 mandatory true; 516 description "a unique service identifier for 517 subscriber L1VC."; 518 } 520 uses subscriber-l1vc-endpoint-attributes; 521 uses subscriber-l1vc-sls-service-attribute; 523 }//end of service list 524 } //end of service container 525 }//service top container 526 } 528 530 5. JSON Example 532 This section provides a JSON example of the YANG module described in 533 Section 4. This example configures one L1VC service with two UNIs 534 that describe the UNI endpoints. The service is configured with the 535 starting time to be 06:06:09 on 2018-09-13 for the service life time 536 of 2419200 seconds (which is corresponds to 28 days). In addition, 537 the service is configured to collect one performance metric, One-way- 538 Delay. 540 { 541 "l1-connectivity": { 542 "access": { 543 "unis": { 544 "uni": [ 545 { 546 "id": "MTL-HQ-Node3-Slot2-Port1", 547 "protocol": "ETH-10GigE_LAN ", 548 "coding": "ETH-10GR-PCS-49 ", 549 "optical_interface": "LR-PMD-clause-52 " 550 }, 551 { 552 "id": "MTL-STL-Node5-Slot4-Port3", 553 "protocol": "ETH-10GigE_LAN ", 554 "coding": "ETH-10GR-PCS-49 ", 555 "optical_interface": "ER-PMD-clause-52 " 556 } 557 ] 558 }, 559 }, 560 "services": { 561 "service": [ 562 { 563 "service-id": "Sub-L1VC-1867-LT-MEGAMART", 564 "endpoint-1": 565 { 566 "id": "MTL-HQ_1867-MEGAMART", 567 "uni": "MTL-HQ-Node3-Slot2-Port1" 568 }, 569 "endpoint-2": 570 { 571 "id": "MTL-STL_1867-MEGAMART", 572 "uni": "MTL-STL-Node5-Slot4-Port3" 573 }, 574 "start-time": "2018-09-13T06:06:09Z", 575 "time-interval": 2419200, 576 "performance-metric": "One-way-Delay " 577 } 578 ] 579 }, 580 } 582 6. Security Considerations 584 The YANG module specified in this document defines a schema for data 585 that is designed to be accessed via network management protocols such 586 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 587 is the secure transport layer, and the mandatory-to-implement secure 588 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 589 is HTTPS, and the mandatory-to-implement secure transport is TLS 590 [RFC8446]. 592 The NETCONF access control model [RFC8341] provides the means to 593 restrict access for particular NETCONF or RESTCONF users to a 594 preconfigured subset of all available NETCONF or RESTCONF protocol 595 operations and content. 597 A number of configuration data nodes defined in this document are 598 writable/deletable (i.e., "config true") These data nodes may be 599 considered sensitive or vulnerable in some network environments. 601 These are the subtrees and data nodes and their sensitivity/ 602 vulnerability: 604 unis: 606 - id 608 Service: 610 - service-id 612 - endpoint-1 614 - endpoint-2 616 - start-time 618 - time-interval 620 - performance-metric 622 The security considerations spelled out in the YANG 1.1 specification 623 [RFC7950] apply for this document as well. 625 7. IANA Considerations 627 It is proposed that IANA should assign new URIs from the "IETF XML 628 Registry" [RFC3688] as follows: 630 URI: urn:ietf:params:xml:ns:yang:ietf-l1csm 631 Registrant Contact: The IESG 632 XML: N/A; the requested URI is an XML namespace. 634 This document registers following YANG modules in the YANG Module 635 Names registry [RFC7950]. 637 name: ietf-l1csm 638 namespace: urn:ietf:params:xml:ns:yang:ietf-l1csm 639 prefix: l1csm 640 reference: RFC XXXX 642 8. Acknowledgements 644 The authors would like to thank Tom Petch for his helpful comments 645 and valuable contributions and Robert Wilton for his review that 646 improved the model significantly. 648 9. Contributors 650 Italo Busi 651 Huawei Technologies 652 Email: Italo.Busi@huawei.com 654 Giuseppe Fioccola 655 Huawei Technologies 656 Email: giuseppe.fioccola@huawei.com 658 10. References 660 10.1. Normative References 662 [MEF63] Metro Ethernet Forum, "Subscriber Layer1 Service 663 Attributes Technical Specification", MEF 63, August 2018. 665 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 666 DOI 10.17487/RFC3688, January 2004, 667 . 669 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 670 and A. Bierman, Ed., "Network Configuration Protocol 671 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 672 . 674 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 675 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 676 . 678 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 679 RFC 6991, DOI 10.17487/RFC6991, July 2013, 680 . 682 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 683 RFC 7950, DOI 10.17487/RFC7950, August 2016, 684 . 686 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 687 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 688 . 690 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 691 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 692 . 694 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 695 Access Control Model", STD 91, RFC 8341, 696 DOI 10.17487/RFC8341, March 2018, 697 . 699 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 700 and R. Wilton, "Network Management Datastore Architecture 701 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 702 . 704 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 705 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 706 . 708 10.2. Informative References 710 [I-D.ietf-ccamp-layer1-types] 711 Zheng, H. and I. Busi, "A YANG Data Model for Layer 1 712 Types", draft-ietf-ccamp-layer1-types-01 (work in 713 progress), July 2019. 715 [RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 716 Virtual Private Networks", RFC 4847, DOI 10.17487/RFC4847, 717 April 2007, . 719 [RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1 720 Virtual Private Network (L1VPN) Basic Mode", RFC 5253, 721 DOI 10.17487/RFC5253, July 2008, 722 . 724 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 725 Classification", RFC 8199, DOI 10.17487/RFC8199, July 726 2017, . 728 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 729 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 730 . 732 Authors' Addresses 734 Young Lee 735 SKKU 736 Sung Kyun Kwan University 737 Seoul 738 South Korea 740 Email: younglee.tx@gmail.com 742 KwangKoog Lee 743 Korea Telecom 744 South Korea 746 Email: kwangkoog.lee@kt.com 748 Haomian Zheng 749 Huawei Technologies 750 H1-1-A043S Huawei Industrial Base, Songshanhu 751 Dongguan, Guangdong 523808 752 China 754 Email: zhenghaomian@huawei.com 756 Dhruv Dhody 757 Huawei Technologies 758 India 760 Email: dhruv.ietf@gmail.com 761 Oscar Gonzalez de Dios 762 Telefonica 764 Email: oscar.gonzalezdedios@telefonica.com 766 Daniele Ceccarelli 767 Ericsson 769 Email: daniele.ceccarelli@ericsson.com