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