idnits 2.17.1 draft-zhang-ccamp-l1-topo-yang-02.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 == Line 160 has weird spacing: '... tp-ref lea...' == Line 162 has weird spacing: '... tp-ref lea...' == Line 197 has weird spacing: '...ogy-ref lea...' == Line 202 has weird spacing: '...ogy-ref lea...' -- The document date (December 22, 2015) is 3046 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) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-04) exists of draft-lee-ccamp-wson-yang-02 == Outdated reference: A later version (-06) exists of draft-vergara-ccamp-flexigrid-yang-01 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group Xian Zhang 2 Internet-Draft Baoquan Rao 3 Intended status: Standards Track Huawei 4 Xufeng Liu 5 Ericsson 7 Expires: June 21, 2016 December 22, 2015 9 A YANG Data Model for Layer 1 Network Topology 11 draft-zhang-ccamp-l1-topo-yang-02.txt 13 Abstract 15 This draft describes a YANG data model to manipulate the topologies 16 of a layer 1 Optical Transport Network (OTN). It is independent of 17 control plane protocols and captures topology related information 18 pertaining to OTN and also enables manipulation of an OTN network 19 via the I2RS interface. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with 24 the provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use Internet-Drafts 34 as reference material or to cite them other than as "work in 35 progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on June 21, 2016. 45 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction ................................................ 2 62 2. Conventions used in this document............................ 3 63 3. Terminology and Notations.................................... 3 64 4. YANG Data Model for Layer 1 Topology ........................ 4 65 4.1. YANG Tree ............................................. 4 66 4.1.1. Augmentation....................................... 5 67 4.1.2. The node and link list............................. 5 68 4.1.3. Notification....................................... 6 69 4.2. YANG Code ............................................. 6 70 5. Security Considerations..................................... 17 71 6. Manageability Considerations................................ 18 72 7. IANA Considerations ........................................ 18 73 8. Acknowledgements ........................................... 18 74 9. References ................................................. 18 75 9.1. Normative References .................................. 18 76 9.2. Informative References ................................ 18 77 10. Contributors' Address...................................... 19 78 Authors' Addresses .............................................19 80 1. Introduction 82 This document defines a data model of a layer one network topology, 83 using YANG [RFC6020]. The model can be used by an application 84 exposing to a management system. Moreover, it can also be used by an 85 application via the I2RS interface [draft-ietf-i2rs-architecture], 86 in the following ways (but not limited to): 88 o to obtain a whole view of the network topology information of 89 its interest e.g., via a network element or maybe a Path 90 Computation Element (PCE) or a network management system within the 91 network ; 93 o to receive notifications with regard to the information of the 94 change of the network topology of its interest; 96 o to enforce the establishment/update of a network topology with 97 the characteristic specified in the data model, e.g., by a network 98 controller or a client controller to manipulate the network provided 99 by the provider for flexible control and management; 101 The YANG model defined in this draft is independent of control plane 102 protocols and captures topology related information pertaining to an 103 Optical Transport Networks (OTN) and also enables manipulation of an 104 OTN network via the I2RS interface. Other network layers, such as 105 fixed Dense Wavelength Switched Optical Network (WSON) and flexible 106 optical networks (a.k.a., flexi-grid networks) are covered in [WSON- 107 YANG] and [Flexi-YANG], respectively. 109 2. Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 113 this document are to be interpreted as described in RFC-2119 114 [RFC2119]. 116 3. Terminology and Notations 118 A simplified graphical representation of the data model is used in 119 this document. The meaning of the symbols in the YANG data tree 120 presented later in this draft is defined in [ietf-netmod-rfc6087bis]. 121 They are provided below for reference. 123 o Brackets "[" and "]" enclose list keys. 125 o Abbreviations before data node names: "rw" means configuration 126 (read-write) and "ro" state data (read-only). 128 o Symbols after data node names: "?" means an optional node, "!" 129 means a presence container, and "*" denotes a list and leaf-list. 131 o Parentheses enclose choice and case nodes, and case nodes are 132 also marked with a colon (":"). 134 o Ellipsis ("...") stands for contents of subtrees that are not 135 shown. 137 4. YANG Data Model for Layer 1 Topology 139 [Editor's note: It was agreed that the model presented in this draft 140 will be augmenting from TE topology YANG, which is not available 141 during the time of writing due to its revision to augment from the 142 generic topology YANG produced in I2RS WG. So, this issue will be 143 addressed in the further versions of this draft.] 145 4.1. YANG Tree 147 module: ietf-layer1topology 148 augment /nt:network/nt:network-types: 149 +--rw l1-network! 150 augment /nt:network: 151 +--rw l1-network-attributes 152 +--rw name? string 153 augment /nt:network/nt:node: 154 +--rw l1-node-attributes 155 +--rw name? string 156 +--rw connectivity-matrix* [id] 157 | +--rw id uint32 158 | +--rw type? enumeration 159 | +--rw in-tp* [tp-ref] 160 | | +--rw tp-ref leafref 161 | +--rw out-tp* [tp-ref] 162 | | +--rw tp-ref leafref 163 | +--rw dir enumeration 164 +--ro oper-status? enumeration 165 augment /nt:network/nt:node/nttopo:termination-point: 166 +--rw physical-info 167 +--rw shelf-id? uint32 168 +--rw board-id? uint32 169 +--rw subcard-id? uint32 170 +--rw port-id? uint32 171 augment /nt:network/nttopo:link: 172 +--rw l1-link-attributes! 173 +--rw source-tp-type enumeration 174 +--rw admin-status? enumeration 175 +--rw link-protection-type? enumeration 176 +--rw switching-capability? identityref 177 +--rw encoding? identityref 178 +--rw srlg 179 | +--rw srlg-values* uint32 180 +--rw (link-attributes)? 181 | +--:(ODU) 182 | | +--rw ODU-type? uint32 183 | | +--rw availabe-resources 184 | | | +--rw granularity enumeration 185 | | | +--rw num? uint32 186 | | | +--rw availability-bitmap* boolean 187 | | +--rw mapping-info 188 | | +--rw mapping-list* string 189 | +--:(client) 190 | +--rw max-bandwidth? uint32 191 | +--rw unreserved-bandwidth? uint32 192 | +--rw local-ip? inet:ip-address 193 | +--rw remote-ip? inet:ip-address 194 +--ro oper-status? enumeration 195 notifications: 196 +---n link-failure 197 | +--ro topology-ref leafref 198 | +--ro link-ref leafref 199 | +--ro admin_status? leafref 200 | +--ro oper-status? leafref 201 +---n node-failure 202 +--ro topology-ref leafref 203 +--ro node-ref leafref 204 +--ro oper-status? leafref 206 4.1.1. Augmentation 208 As can be seen in the YANG module presented augments from a more 209 generic network topology model, i.e., the ietf-network-topology YANG 210 module as specified in [draft-ietf-i2rs-yang-network-topo]. This is 211 to follow the network model structure suggested in [draft-ietf-i2rs- 212 yang-network-topo] figure 1. 214 [Editor's note: how TE topo YANG fits in this figure has been 215 discussed and yet to be updated in that draft.] 217 4.1.2. The node and link list 219 The module presented in this draft contains all the nodes and links 220 information pertaining to a layer one network. As specified in the 221 ietf-network YANG module, a node is identified by the node-id, which 222 is unique within the network. Within the nodes, all the interfaces 223 pertaining to this node and their potential capabilities/constraints 224 SHOULD be present. Besides this, the constraints associated with a 225 node as a whole SHOULD also be present, such as the connectivity 226 constraints introduced due to abstraction or due to the hardware 227 limitations. 229 Similarly, a link is identified by the link-id, which is unique 230 within a node. It includes the association with nodes as well as 231 interfaces. Moreover, it includes information that is of interest to 232 the management and I2RS client, for purposes, such as path 233 computation, monitoring etc. For termination points, physical 234 information is provided as an optional feature and it provides 235 additional information to allow management/I2RS client to be better 236 informed of this attribute and can help visualize and simply the 237 operation of termination points selection. 239 [editor's note]: for next update: any specific information related 240 to an OTN interface has to be described in the context of 241 technologic specific extension of OTN-TDM ISCD". 243 Since for an optical transport network, its client interface 244 attributes may be different with that of the links within the 245 network. For full control purpose, this attributes and information 246 are also captured and listed in this YANG module. 248 4.1.3. Notification 250 Two types of notifications are introduced: node failure and link 251 failure. 253 4.2. YANG Code 255 file "ietf-layer1topology@2015-12-20.yang" 257 module ietf-layer1topology { 258 yang-version 1; 260 namespace "urn:ietf:params:xml:ns:yang:ietf-layer1topology"; 261 prefix "l1topo"; 263 import ietf-inet-types { 264 prefix "inet"; 265 } 266 import ietf-network { 267 prefix "nd"; 268 } 270 import ietf-network-topology { 271 prefix "lnk"; 272 } 274 import ietf-te-types { 275 prefix "ietf-te-types"; 276 } 277 organization 278 "Internet Engineering Task Force (IETF) CCAMP WG"; 279 contact 280 "ID-draft editor: zhang.xian@huawei.com"; 282 description 283 "This module defines a protocol independent Layer One/OTN 284 topology data model."; 286 revision 2015-12-20{ 287 description 288 "Initial version."; 289 reference 290 "draft-zhang-ccamp-l1-topo-yang-00.txt"; 291 } 293 /* 294 Groupings 295 */ 297 grouping srlg-attributes { 298 description 299 "Shared Risk Link Group Attributes"; 300 reference 301 "RFC 4203: OSPF Extensions in Support of Generalized 302 Multi-Protocol Label Switching (GMPLS)"; 303 leaf-list srlg-values { 304 type uint32; 305 description "SRLG value list"; 306 } 307 } 309 grouping l1-network-type { 310 container l1-network { 311 presence "indicates a L1 network, i.e., Optical 312 Transport Network (OTN)."; 313 description "l1 network type"; 314 } 315 description "l1-network-type"; 316 } 318 grouping l1-network-attributes { 319 container l1-network-attributes { 320 leaf name { 321 type string; 322 description "the network name"; 323 } 324 description "name attribute for l1 network"; 325 } 326 description "l1-network-attributes"; 327 } 329 grouping l1-node-attributes { 330 description "l1-node-attributes"; 331 container l1-node-attributes { 332 description "l1-node-attributes"; 333 leaf name { 334 type string; 335 description "a name for this node."; 336 } 338 list connectivity-matrix { 339 key "id"; 341 description 342 "This describes the connectivity constraints within 343 a node in the network. It can be one matrix or a set 344 of matrixes. Further details, read the reference 345 provided below."; 346 reference 347 "https://tools.ietf.org/html/draft-ietf-ccamp-general 348 -constraint-encode-16 Section 2.1"; 350 leaf id { 351 type uint32; 352 description "matrix id"; 353 } 354 leaf type { 355 type enumeration { 356 enum fixed { 357 value 0; 358 description "Fixed"; 359 } 360 enum dynamic { 361 value 1; 362 description "Dynamic/changeable"; 363 } 364 } 365 description 366 "This field describes the attribute of a 367 connectivity matrix, i.e., whether it is 368 fixed or switched."; 369 } 370 list in-tp { 371 key "tp-ref"; 373 description 374 "This list describes a (sub)-set of ingoing 376 interfaces within a node that may have 377 connectivity constraints. 378 Note: directionality may not be relevant 379 and it is decided by the dir parameter."; 381 leaf tp-ref { 382 type leafref { 383 path "../../../../lnk:termination-point/"+ 384 "lnk:tp-id"; 385 } 386 description "reference to an incoming interface, 387 must be within the same node"; 388 } 389 } 390 list out-tp { 391 key "tp-ref"; 393 description 394 "This list describes a (sub)-set of outgoing 395 interfaces within a node that may have 396 connectivity constraints. 397 Note: directionality may not be relevant and 398 it is decided by the dir parameter."; 400 leaf tp-ref { 401 type leafref { 402 path "../../../../lnk:termination-point"+ 403 "/lnk:tp-id"; 404 } 405 description "reference to an outgoing interface, 406 must be within the same node"; 407 } 408 } 409 leaf dir{ 410 type enumeration{ 411 enum "uni-dir"{ 412 description 413 "the matrix is unidirectional."; 414 } 415 enum "bi-dir"{ 416 description 417 "this matrix is bidirectional."; 419 } 420 } 421 mandatory true; 422 description 423 "the directionality attribute of a connc. matrix."; 425 } 426 } 428 leaf oper-status { 429 type enumeration { 430 enum "unknown" { 431 description "unknown - lost connect with control 432 plane."; 433 } 434 enum "up" { 435 description "normal"; 436 } 437 enum "down" { 438 description "not available"; 439 } 440 } 442 config false; 443 description "operational status of a node"; 444 } 445 } 446 } 448 grouping l1-link-attributes { 449 description "l1-link-attributes"; 450 container l1-link-attributes { 451 presence "L1 link attributes"; 452 description "l1 link attributes"; 453 leaf source-tp-type { 454 type enumeration { 455 enum "client-side" { 456 description "client side"; 457 } 458 enum "line-side" { 459 description "line side"; 460 } 461 } 462 mandatory true; 463 description 464 "the type of a port:0-client side; 1 - line side"; 465 } 466 leaf admin-status { 467 type enumeration { 468 enum "up" { 469 description "up"; 470 } 472 enum "down" { 473 description "normal"; 474 } 475 } 476 description "administrative status of a link"; 477 } 479 leaf link-protection-type { 480 type enumeration { 481 enum "extra-traffic" { 482 description "Extra traffic"; 483 } 484 enum "unprotected" { 485 description "unprotected"; 486 } 487 enum "shared" { 488 description "Shared"; 489 } 490 enum "1-for-1" { 491 description "Dedicated one for one protection"; 492 } 493 enum "1-plus-1" { 494 description "Dedicated one plus one protection"; 495 } 496 enum "enhanced" { 497 description "a protection type that is more reliable 498 than Dedicated 1+1, e.g.,4 fiber BLSR/MS-SPRING."; 499 } 500 } 501 description 502 "Link Protection Type configured for this link"; 503 reference 504 "RFC3471: Generalized Multi-Protocol Label Switching 505 (GMPLS) Signaling Functional Description."; 506 } 508 leaf switching-capability { 509 type identityref{ 510 base ietf-te-types:switching-capabilities; 511 } 512 description 513 "the switching capability supported by the link"; 514 } 516 leaf encoding { 517 type identityref{ 518 base ietf-te-types:lsp-encoding-types; 520 } 521 description 522 "the encoding type supported by this link."; 523 } 525 container srlg { 526 uses srlg-attributes; 527 description " the SRLG values of a link"; 528 } 530 choice link-attributes { 531 case ODU { 532 leaf ODU-type { 533 type uint32; 534 description "link capacity, subject to change 535 to the type of enumeration"; 536 } 538 container availabe-resources { 539 leaf granularity { 540 type enumeration { 541 enum "1.25G" { 542 description "1.25G"; 543 } 544 enum "2.5G" { 545 description "2.5G"; 546 } 547 } 548 mandatory true; 549 description "the base unit for unreserved-bandwidth 550 description"; 551 } 552 leaf num { 553 type uint32; 554 description "number * granularity = max-bandwidth"; 555 } 556 leaf-list availability-bitmap { 557 type boolean; 558 description "0-avaialble, 1- unavaialbe"; 560 } 561 description "describe what is available in the unit 562 of granularity"; 563 } 564 container mapping-info { 565 leaf-list mapping-list { 566 type string; 568 description "it can be one or multiple mapping route"; 569 } 570 description "mapping supported by this link; subject 571 to further change"; 572 } 573 } 574 case client { 575 leaf max-bandwidth { 576 type uint32; 577 description "max bandwidth supported by this client 578 facing link"; 579 } 580 leaf unreserved-bandwidth { 581 type uint32; 582 description "available bandwidth on this link"; 583 } 584 leaf local-ip { 585 type inet:ip-address; 586 description "the local-end ip address of a link"; 587 } 588 leaf remote-ip { 589 type inet:ip-address; 590 description "the remote-end ip address of a link"; 591 } 592 } 593 description "attributes for a client interface"; 594 } 596 leaf oper-status { 597 type enumeration { 598 enum "unknown" { 599 description "unknown-lost connection with control 600 plane"; 601 } 602 enum "normal" { 603 description "normal"; 604 } 605 enum "down" { 606 description "down"; 608 } 609 enum "degraded" { 610 description "degraded, temporarily unusable"; 611 } 612 } 614 config false; 616 description "status of a link"; 617 } 618 } 619 } 621 grouping l1-tp-attributes { 622 description "l1-tp-attributes"; 623 container physical-info { 624 description "physical info of an termination point/port"; 625 leaf shelf-id { 626 type uint32; 627 description "shelf-id of which this tp belongs to"; 628 } 629 leaf board-id { 630 type uint32; 631 description "board-id of which this tp belongs to"; 632 } 633 leaf subcard-id { 634 type uint32; 635 description "subcard id information, if no such info.,"+ 636 "fill in 0xff."; 637 } 638 leaf port-id { 639 type uint32; 640 description "port-id of which this tp belongs to"; 641 } 642 } 643 } 645 /* 646 * Data nodes 647 */ 649 augment "/nd:networks/nd:network/nd:network-types" { 650 uses l1-network-type; 651 description "augment network types to include L1 newtork"; 652 } 654 augment "/nd:networks/nd:network" { 655 when "nd:network-types/l1-network" { 656 description "Augment only for L1 network"; 657 } 658 uses l1-network-attributes; 659 description "Augment network configuration"; 660 } 662 augment "/nd:networks/nd:network/nd:node" { 664 when "nd:network-types/l1-network" { 665 description "Augment only for L1 network"; 666 } 667 description "Augment node configuration"; 669 uses l1-node-attributes; 670 } 672 augment "/nd:networks/nd:network/nd:node/lnk:termination-point" { 673 when "nd:network-types/l1-network" { 674 description "Augment only for L1 network"; 675 } 676 description "Augment tp configuration"; 678 uses l1-tp-attributes; 679 } 681 augment "/nd:networks/nd:network/lnk:link" { 682 when "nd:network-types/l1-network" { 683 description "Augment only for L1 network."; 684 } 685 description "Augment link configuration"; 687 uses l1-link-attributes; 688 } 690 notification link-failure { 691 leaf topology-ref { 692 type leafref { 693 path "/nd:networks/nd:network/nd:network-id"; 694 } 695 mandatory true; 696 description "the topology reference of which" 697 +"this link belongs to"; 698 } 699 leaf link-ref { 700 type leafref { 701 path "/nd:networks/nd:network[nd:network-id= current ()"+ 702 "/../topology-ref]/lnk:link/lnk:link-id"; 703 } 704 mandatory true; 705 description ""; 706 } 707 leaf admin_status { 708 type leafref { 709 path 710 "/nd:networks/nd:network/lnk:link[lnk:link-id ="+ 712 "current()/../link-ref]/l1-link-attributes/admin-status"; 713 } 714 description "admin status of the reported link"; 715 } 716 leaf oper-status { 717 type leafref { 718 path 719 "/nd:networks/nd:network/lnk:link[lnk:link-id = current()" 720 +"/../link-ref]/l1-link-attributes/oper-status"; 721 } 722 description ""; 723 } 724 description 725 "link failure information"; 726 } //notification-link failure 728 notification node-failure { 729 leaf topology-ref { 730 type leafref { 731 path "/nd:networks/nd:network/nd:network-id"; 732 } 733 mandatory true; 734 description ""; 735 } 736 leaf node-ref { 737 type leafref { 738 path "/nd:networks/nd:network[nd:network-id= current ()"+ 739 "/../topology-ref]/nd:node/nd:node-id"; 740 } 741 mandatory true; 742 description ""; 743 } 744 leaf oper-status { 745 type leafref { 746 path 747 "/nd:networks/nd:network/nd:node[nd:node-id = current()" 748 +"/../node-ref]/l1-node-attributes/oper-status"; 750 } 751 description ""; 752 } 753 description 754 "node failure information"; 755 } 756 } 757 759 5. Security Considerations 761 Since the data model defined in this draft is manipulated via the 762 I2RS interface. The security concerns mentioned in [draft-ietf-i2rs- 763 architecture] also applies to this draft. 765 The YANG module defined in this memo is designed to be accessed via 766 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 767 secure transport layer and the mandatory-to-implement secure 768 transport is SSH [RFC6242]. The NETCONF access control model 769 [RFC6536] provides the means to restrict access for particular 770 NETCONF users to a pre-configured subset of all available NETCONF 771 protocol operations and content. 773 There are a number of data nodes defined in the YANG module which 774 are writable/creatable/deletable (i.e., config true, which is the 775 default). These data nodes may be considered sensitive or 776 vulnerable in some network environments. Write operations (e.g., 777 ) to these data nodes without proper protection can 778 have a negative effect on network operations. 780 [Editor's note: to List specific subtrees and data nodes and their 781 sensitivity/vulnerability.] 783 6. Manageability Considerations 785 TBD. 787 7. IANA Considerations 789 TBD. 791 8. Acknowledgements 793 The initial YANG model specified in this draft is based on draft- 794 clemm-i2rs-yang-network-topo but it is modified according to the 795 features of the layer one networks. 797 We would like to thank the authors of the above mentioned draft for 798 their helpful discussion during the creation of this draft. 800 9. References 802 9.1. Normative References 804 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 805 requirements levels", RFC 2119, March 1997. 807 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 808 Network Configuration Protocol (NETCONF)", RFC 6020, 809 October 2010. 811 9.2. Informative References 813 [draft-ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., 814 Ward, D., Nadeau T., "An Architecture for the Interface to 815 the Routing System", draft-ietf-i2rs-architecture-08, work 816 in progress, January 2015; 818 [draft-ietf-i2rs-yang-network-topo] Clemm A., Medved J., Tkacik T., 819 Varga R., et al, "A YANG Data Model for Network 820 Topologies", draft-ietf-i2rs-yang-network-topo-01, work in 821 progress, June 2015; 823 [ietf-netmod-rfc6087bis] Bierman, A., "Guidelines for Authors and 824 Reviewers of YANG Data Model Documents", draft-ietf- 825 netmod-rfc6087bis-01, work in progress, October 2014. 827 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, 828 "Network Configuration Protocol (NETCONF)", RFC6241, June 829 2011. 831 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 832 Shell (SSH)", RFC 6242, June 2011. 834 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 835 Protocol (NETCONF) Access Control Model", RFC 6536, March 836 2012. 838 [WSON-YANG] Lee, Y., et al, " A Yang Data Model for WSON Optical 839 Networks", draft-lee-ccamp-wson-yang-02, work in progress, 840 July 2015. 842 [Flexi-YANG] Lopez de Varga, J.E., et al, "YANG data model for 843 Flexi-Grid Optical Networks", draft-vergara-ccamp- 844 flexigrid-yang-01, work in progress, July 2015. 846 10. Contributors' Address 848 Sergio Belotti 849 Alcatel-Lucent 850 Sergio.belotti@alcatel-lucent.com 852 Authors' Addresses 853 Xian Zhang 854 Huawei Technologies 855 Email: zhang.xian@huawei.com 857 Baoquan Rao 858 Huawei Technologies 859 raobaoquan@huawei.com 861 Xufeng Liu 862 Ericsson 863 Xufeng.liu@ericsson.com