idnits 2.17.1 draft-dharini-netmod-dwdm-if-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ITU.G874.1], [ITU.G698.2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 314 has weird spacing: '...code-id uin...' == Line 315 has weird spacing: '...de-type uint8...' == Line 321 has weird spacing: '...code-id uint...' == Line 322 has weird spacing: '...de-type uint8...' == Line 338 has weird spacing: '...de-type uint8...' == (1 more instance...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 19, 2015) is 3111 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: 'ITU-T G.7710' is mentioned on line 118, but not defined == Missing Reference: 'RFC6241' is mentioned on line 576, but not defined == Missing Reference: 'RFC6242' is mentioned on line 578, but not defined == Missing Reference: 'RFC6536' is mentioned on line 578, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC3688' is mentioned on line 586, but not defined == Missing Reference: 'RFC6020' is mentioned on line 600, but not defined == Unused Reference: 'RFC2863' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'RFC2578' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC2579' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'RFC2580' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'RFC6205' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'ITU.G709' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'ITU.G959.1' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'ITU.G826' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'ITU.G8201' is defined on line 724, but no explicit reference was found in the text == Unused Reference: 'ITU.G7710' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 752, but no explicit reference was found in the text == Unused Reference: 'I-D.kdkgall-ccamp-dwdm-if-mng-ctrl-fwk' is defined on line 756, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G698.2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G709' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G872' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G798' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G874' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G874.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G959.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G826' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G8201' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G694.1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.G7710' -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-01) exists of draft-kdkgall-ccamp-dwdm-if-mng-ctrl-fwk-00 Summary: 2 errors (**), 0 flaws (~~), 28 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G.Galimberti, Ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track R.Kunze, Ed. 5 Expires: April 21, 2016 Deutsche Telekom 6 K. Lam, Ed. 7 Alcatel-Lucent 8 D. Hiremagalur, Ed. 9 G. G.Grammel, Ed. 10 Juniper 11 L.Fang, Ed. 12 G.Ratterree, Ed. 13 Microsoft 14 October 19, 2015 16 A YANG model to manage the optical interface parameters for an external 17 transponder in a WDM network 18 draft-dharini-netmod-dwdm-if-yang-00 20 Abstract 22 This memo defines a Yang model that translates the SNMP mib module 23 defined in draft-galikunze-ccamp-dwdm-if-snmp-mib for managing single 24 channel optical interface parameters of DWDM applications. This 25 model is to support the optical parameters specified in ITU-T G.698.2 26 [ITU.G698.2] and application identifiers specified in ITU-T G.874.1 27 [ITU.G874.1] . Note that G.874.1 encompasses vendor-specific codes, 28 which if used would make the interface a single vendor IaDI and could 29 still be managed. 31 The Yang model defined in this memo can be used for Optical 32 Parameters monitoring and/or configuration of the endpoints of the 33 multi-vendor IaDI optical link. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on April 21, 2016. 57 Copyright Notice 59 Copyright (c) 2015 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. The Internet-Standard Management Framework . . . . . . . . . 4 76 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 4.1. Optical Parameters Description . . . . . . . . . . . . . 5 79 4.1.1. Rs-Ss Configuration . . . . . . . . . . . . . . . . . 6 80 4.1.2. Table of Application Codes . . . . . . . . . . . . . 7 81 4.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 7 82 4.3. Optical Interface for external transponder in a WDM 83 network . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 5. Structure of the Yang Module . . . . . . . . . . . . . . . . 8 85 6. Yang Module . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 89 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 11.2. Informative References . . . . . . . . . . . . . . . . . 17 93 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 94 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 18 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 97 1. Introduction 99 This memo defines a Yang model that translates the SNMP mib module 100 defined in draft-galikunze-ccamp-dwdm-if-snmp-mib for managing single 101 channel optical interface parameters of DWDM applications, using the 102 approach specified in G.698.2. This model is to support the optical 103 parameters specified in ITU-T G.698.2 [ITU.G698.2], application 104 identifiers specified in ITU-T G.874.1 [ITU.G874.1] and the Optical 105 Power at Transmitter and Receiver side. Note that G.874.1 106 encompasses vendor-specific codes, which if used would make the 107 interface a single vendor IaDI and could still be managed.` 109 [Editor's note: In G.698.2 this corresponds to the optical path from 110 point S to R; network media channel is also used and explained in 111 draft-ietf-ccamp-flexi-grid-fwk-02] 113 Management will be performed at the edges of the network media 114 channel (i.e., at the transmitters and receivers attached to the S 115 and R reference points respectively) for the relevant parameters 116 specified in G.698.2 [ITU.G698.2], G.798 [ITU.G798], G.874 117 [ITU.G874], and the performance parameters specified in G.7710/Y.1701 118 [ITU-T G.7710] and G.874.1 [ITU.G874.1]. 120 G.698.2 [ITU.G698.2] is primarily intended for metro applications 121 that include optical amplifiers. Applications are defined in G.698.2 122 [ITU.G698.2] using optical interface parameters at the single-channel 123 connection points between optical transmitters and the optical 124 multiplexer, as well as between optical receivers and the optical 125 demultiplexer in the DWDM system. This Recommendation uses a 126 methodology which does not explicitly specify the details of the 127 optical network between reference point Ss and Rs, e.g., the passive 128 and active elements or details of the design. The Recommendation 129 currently includes unidirectional DWDM applications at 2.5 and 10 130 Gbit/s (with 100 GHz and 50 GHz channel frequency spacing). Work is 131 still under way for 40 and 100 Gbit/s interfaces. There is 132 possibility for extensions to a lower channel frequency spacing. 133 This document specifically refers to the "application code" defined 134 in the G.698.2 [ITU.G698.2] and included in the Application 135 Identifier defined in G.874.1 [ITU.G874.1] and G.872 [ITU.G872], plus 136 a few optical parameters not included in the G.698.2 application code 137 specification. 139 This draft refers and supports the draft-kdkgall-ccamp-dwdm-if-mng- 140 ctrl-fwk 142 The building of a yang model describing the optical parameters 143 defined in G.698.2 [ITU.G698.2], and reflected in G.874.1 144 [ITU.G874.1], allows the different vendors and operator to retrieve, 145 provision and exchange information across the G.698.2 multi-vendor 146 IaDI in a standardized way. In addition to the parameters specified 147 in ITU recommendations the Yang models support also the "vendor 148 specifica application identifier", the Tx and Rx power at the Ss and 149 Rs points and the channel frequency. 151 The Yang Model, reporting the Optical parameters and their values, 152 characterizes the features and the performances of the optical 153 components and allow a reliable link design in case of multi vendor 154 optical networks. 156 Although RFC 3591 [RFC3591], which draft-galikunze-ccamp-DWDM-if- 157 snmp-mib is extending, describes and defines the SNMP MIB of a number 158 of key optical parameters, alarms and Performance Monitoring, as this 159 RFC is over a decade old, it is primarily pre-OTN, and a more 160 complete and up-to-date description of optical parameters and 161 processes can be found in the relevant ITU-T Recommendations. The 162 same considerations can be applied to the RFC 4054 [RFC4054]. 164 2. The Internet-Standard Management Framework 166 For a detailed overview of the documents that describe the current 167 Internet-Standard Management Framework, please refer to section 7 of 168 RFC 3410 [RFC3410]. 170 This memo specifies a Yang model for optical interfaces. 172 3. Conventions 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119] In 177 the description of OIDs the convention: Set (S) Get (G) and Trap (T) 178 conventions will describe the action allowed by the parameter. 180 4. Overview 181 Figure 1 shows a set of reference points, for single-channel 182 connection between transmitters (Tx) and receivers (Rx). Here the 183 DWDM network elements include an OM and an OD (which are used as a 184 pair with the opposing element), one or more optical amplifiers and 185 may also include one or more OADMs. 187 +-------------------------------------------------+ 188 Ss | DWDM Network Elements | Rs 189 +--+ | | | \ / | | | +--+ 190 Tx L1--|->| \ +------+ +------+ / |--|-->Rx L1 191 +---+ | | | | | +------+ | | | | | +--+ 192 +---+ | | | | | | | | | | | | +--+ 193 Tx L2--|->| OM |-->|------|->| OADM |--|------|->| OD |--|-->Rx L2 194 +---+ | | | | | | | | | | | | +--+ 195 +---+ | | | | | +------+ | | | | | +--+ 196 Tx L3--|->| / | DWDM | | ^ | DWDM | \ |--|-->Rx L3 197 +---+ | | / | Link +----|--|----+ Link | \ | | +--+ 198 +-----------+ | | +----------+ 199 +--+ +--+ 200 | | 201 Rs v | Ss 202 +-----+ +-----+ 203 |RxLx | |TxLx | 204 +-----+ +-----+ 205 Ss = reference point at the DWDM network element tributary output 206 Rs = reference point at the DWDM network element tributary input 207 Lx = Lambda x 208 OM = Optical Mux 209 OD = Optical Demux 210 OADM = Optical Add Drop Mux 212 from Fig. 5.1/G.698.2 214 Figure 1: External transponder in WDM netwoks 216 4.1. Optical Parameters Description 218 The link between the external transponders through a WDM network 219 media channels are managed at the edges, i.e. at the transmitters 220 (Tx) and receivers (Rx) attached to the S and R reference points 221 respectively. The set of parameters that could be managed are 222 defined by the "application code" notation 224 The definitions of the optical parameters are provided below to 225 increase the readability of the document, where the definition is 226 ended by (R) the parameter can be retrieve with a read, when (W) it 227 can be provisioned by a write, (R,W) can be either read or written. 229 4.1.1. Rs-Ss Configuration 231 The Rs-Ss configuration table allows configuration of Central 232 Frequency, Power and Application codes as described in [ITU.G698.2] 233 and G.694.1 [ITU.G694.1] 234 This parameter report the current Transceiver Output power, it can be 235 either a setting and measured value (G, S). 237 Central frequency (see G.694.1 Table 1) (see G.694.1 Table 1): 238 This parameter indicates the Central frequency value that Ss and 239 Rs will be set to work (in THz). See the details in Section 6/ 240 G.694.1 (G, S). 242 Single-channel application codes(see G.698.2): 243 This parameter indicates the transceiver application code at Ss 244 and Rs as defined in [ITU.G698.2] Chapter 5.4 - this parameter can 245 be called Optical Interface Identifier OII as per [draft- 246 martinelli-wson-interface-class](G). 248 Number of Single-channel application codes Supported 249 This parameter indicates the number of Single-channel application 250 codes supported by this interface (G). 252 Current Laser Output power: 253 This parameter report the current Transceiver Output power, it can 254 be either a setting and measured value (G, S). 256 Current Laser Input power: 257 This parameter report the current Transceiver Input power (G). 259 +---------------------------------------------+---------+-----------+ 260 | PARAMETERS | Get/Set | Reference | 261 +---------------------------------------------+---------+-----------+ 262 | Central frequency Value | G,S | G.694.1 | 263 | | | S.6 | 264 | Single-channel application codes | G | G.698.2 | 265 | | | S.5.3 | 266 | Number of Single-channel application codes | G | N.A. | 267 | Supported | | | 268 | Current Output Power | G,S | N.A. | 269 | Current Input Power | G | N.A. | 270 +---------------------------------------------+---------+-----------+ 272 Table 1: Rs-Ss Configuration 274 4.1.2. Table of Application Codes 276 This table has a list of Application codes supported by this 277 interface at point R are defined in G.698.2. 279 Application code Identifier: 280 The Identifier for the Application code. 282 Application code Type: 283 This parameter indicates the transceiver type of application code 284 at Ss and Rs as defined in [ITU.G874.1], that is used by this 285 interface Standard = 0, PROPRIETARY = 1 286 The first 6 octets of the printable string will be the OUI 287 (organizationally unique identifier) assigned to the vendor 288 whose implementation generated the Application Identifier Code. 290 Application code Length: 291 The number of octets in the Application Code. 293 Application code: 294 This is the application code that is defined in G.698.2 or the 295 vendor generated code which has the OUI. 297 4.2. Use Cases 299 The use cases are described in draft-kdkgall-ccamp-dwdm-if-mng-ctrl- 300 fwk 302 4.3. Optical Interface for external transponder in a WDM network 304 The ietf-ext-xponder-wdm-if is an augment to the ietf-interface. It 305 allows the user to set the application code/vendor transceiver class/ 306 Central frequency and the output power. The module can also be used 307 to get the list of supported application codes/transceiver class and 308 also the Central frequency/output power/input power of the interface. 310 module: ietf-ext-xponder-wdm-if 311 augment /if:interfaces/if:interface: 312 +--rw optIfOChRsSs 313 +--rw if-current-application-code 314 | +--rw application-code-id uint8 315 | +--rw application-code-type uint8 316 | +--rw application-code-length uint8 317 | +--rw application-code? string 318 +--ro if-supported-application-codes 319 | +--ro number-application-codes-supported? uint32 320 | +--ro application-codes-list* [application-code-id] 321 | +--ro application-code-id uint8 322 | +--rw application-code-type uint8 323 | +--rw application-code-length uint8 324 | +--ro application-code? string 325 +--rw output-power? int32 326 +--ro input-power? int32 327 +--rw central-frequency? uint32 329 notifications: 330 +---n opt-if-och-central-frequency-change 331 | +--ro if-name? leafref 332 | +--ro new-central-frequency 333 | +--ro central-frequency? uint32 334 +---n opt-if-och-application-code-change 335 | +--ro if-name? leafref 336 | +--ro new-application-code 337 | +--ro application-code-id? uint8 338 | +--rw application-code-type uint8 339 | +--rw application-code-length uint8 340 | +--ro application-code? string 342 5. Structure of the Yang Module 344 ietf-ext-xponder-wdm-if is a top level model for the support of this 345 feature. 347 6. Yang Module 349 The ietf-ext-xponder-wdm-if is defined as an extension to ietf 350 interfaces. 352 file "ietf-ext-xponder-wdm-if.yang" 353 module ietf-ext-xponder-wdm-if { 354 namespace "urn:ietf:params:xml:ns:yang:ietf-ext-xponder-wdm-if"; 355 prefix ietf-ext-xponder-wdm-if; 357 import ietf-interfaces { 358 prefix if; 359 } 361 organization 362 "IETF NETMOD (NETCONF Data Modelling Language) 363 Working Group"; 365 contact 366 "WG Web: 367 WG List: 369 WG Chair: Thomas Nadeau 370 372 WG Chair: Juergen Schoenwaelder 373 375 Editor: Dharini Hiremagalur 376 "; 378 description 379 "This module contains a collection of YANG definitions for 380 configuring Optical interfaces. 382 Copyright (c) 2013 IETF Trust and the persons identified 383 as authors of the code. All rights reserved. 385 Redistribution and use in source and binary forms, with or 386 without modification, is permitted pursuant to, and 387 subject to the license terms contained in, the Simplified 388 BSD License set forth in Section 4.c of the IETF Trust's 389 Legal Provisions Relating to IETF Documents 390 (http://trustee.ietf.org/license-info)."; 392 revision "2015-06-24" { 393 description 394 "Revision 4.0"; 396 reference 397 " draft-dharini-netmod-dwdm-if-yang 3.0"; 398 } 399 revision "2015-02-24" { 400 description 401 "Revision 3.0"; 403 reference 404 " draft-dharini-netmod-dwdm-if-yang 3.0"; 405 } 406 revision "2014-11-10" { 407 description 408 "Revision 2.0"; 409 reference 410 " "; 411 } 412 revision "2014-10-14" { 413 description 414 "Revision 1.0"; 415 reference 416 " "; 417 } 418 revision "2014-05-10" { 419 description 420 "Initial revision."; 421 reference 422 "RFC XXXX: A YANG Data Model for Optical 423 Management of an Interface for an external 424 transponder in a WDM netwrok"; 425 } 427 grouping opt-if-och-application-code { 428 description "Application code entity."; 429 leaf application-code-id { 430 type uint8 { 431 range "1..255"; 432 } 433 description 434 "Id for the Application code"; 435 } 436 leaf application-code-type { 437 type uint8 { 438 range "0..1"; 439 } 440 description 441 "Type for the Application code 442 0 - Standard, 1 - Proprietory 443 When the Type is Proprietory, then the 444 first 6 octets of the application-code 445 will be the OUI (organizationally unique 446 identifier)"; 448 } 449 leaf application-code-length { 450 type uint8 { 451 range "1..255"; 452 } 453 description 454 "Number of octets in the Application code"; 456 } 457 leaf application-code { 458 type string { 459 length "1..255"; 460 } 461 description "This parameter indicates the 462 transceiver application code at Ss and Rs as 463 defined in [ITU.G698.2] Chapter 5.3, that 464 is/should be used by this interface. 465 The optIfOChApplicationsCodeList has all the 466 application codes supported by this 467 interface."; 469 } 470 } 472 grouping opt-if-och-application-code-list { 473 description "List of Application codes group."; 474 leaf number-application-codes-supported { 475 type uint32; 476 description "Number of Application codes 477 supported by this interface"; 478 } 479 list application-code-list { 480 key "application-code-id"; 481 description "List of the application codes"; 482 uses opt-if-och-application-code; 483 } 484 } 486 grouping opt-if-och-power { 487 description "Interface optical Power"; 488 leaf output-power { 489 type int32; 490 units ".01dbm"; 491 description "The output power for this interface in 492 .01 dBm."; 493 } 495 leaf input-power { 496 type int32; 497 units ".01dbm"; 498 config false; 499 description "The current input power of this 500 interface"; 501 } 502 } 504 grouping opt-if-och-central-frequency { 505 description "Interface Central Frequency"; 506 leaf central-frequency { 507 type uint32; 508 description "This parameter indicate This parameter 509 indicates the frequency of this interface "; 511 } 512 } 514 notification opt-if-och-central-frequency-change { 515 description "A change of Central Frequency has been 516 detected."; 517 leaf "if-name" { 518 type leafref { 519 path "/if:interfaces/if:interface/if:name"; 520 } 521 description "Interface name"; 522 } 523 container opt-if-och-central-frequency { 524 description "The new Central Frequency of the 525 interface"; 526 uses opt-if-och-central-frequency; 527 } 528 } 530 notification opt-if-och-application-code-change { 531 description "A change of Application code has been 532 detected."; 533 leaf "if-name" { 534 type leafref { 535 path "/if:interfaces/if:interface/if:name"; 536 } 537 description "Interface name"; 538 } 539 container new-application-code { 540 description "The new application code for the 541 interface"; 542 uses opt-if-och-application-code; 543 } 544 } 546 augment "/if:interfaces/if:interface" { 547 description "Parameters for an optical interface"; 548 container optIfOChRsSs { 549 description "RsSs path configuration for an interface"; 550 container if-current-application-code { 551 description "Current Application code of the 552 interface"; 553 uses opt-if-och-application-code; 554 } 556 container if-supported-application-codes { 557 config false; 558 description "Supported Application codes of 559 the interface"; 560 uses opt-if-och-application-code-list; 561 } 563 uses opt-if-och-power; 565 uses opt-if-och-central-frequency; 567 } 568 } 569 } 571 573 7. Security Considerations 575 The YANG module defined in this memo is designed to be accessed via 576 the NETCONF protocol [RFC6241]. he lowest NETCONF layer is the secure 577 transport layer and the mandatory-to-implement secure transport is 578 SSH [RFC6242]. The NETCONF access control model [RFC6536] provides 579 the means to restrict access for particular NETCONF users to a pre- 580 configured subset of all available NETCONF protocol operation and 581 content. 583 8. IANA Considerations 585 This document registers a URI in the IETF XML registry [RFC3688]. 586 Following the format in [RFC3688], the following registration is 587 requested to be made: 589 URI: urn:ietf:params:xml:ns:yang:ietf-interfaces:ietf-ext-xponder- 590 wdm-if 592 Registrant Contact: The IESG. 594 XML: N/A, the requested URI is an XML namespace. 596 This document registers a YANG module in the YANG Module Names 597 registry [RFC6020]. 599 This document registers a YANG module in the YANG Module Names 600 registry [RFC6020]. 602 prefix: ietf-ext-xponder-wdm-if reference: RFC XXXX 604 9. Acknowledgements 606 Gert Grammel is partly funded by European Union Seventh Framework 607 Programme under grant agreement 318514 CONTENT. 609 10. Contributors 610 Dean Bogdanovic 611 Juniper Networks 612 Westford 613 U.S.A. 614 email deanb@juniper.net 616 Bernd Zeuner 617 Deutsche Telekom 618 Darmstadt 619 Germany 620 email B.Zeuner@telekom.de 622 Arnold Mattheus 623 Deutsche Telekom 624 Darmstadt 625 Germany 626 email a.mattheus@telekom.de 628 Manuel Paul 629 Deutsche Telekom 630 Berlin 631 Germany 632 email Manuel.Paul@telekom.de 634 Walid Wakim 635 Cisco 636 9501 Technology Blvd 637 ROSEMONT, ILLINOIS 60018 638 UNITED STATES 639 email wwakim@cisco.com 641 11. References 643 11.1. Normative References 645 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 646 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 647 . 649 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", BCP 14, RFC 2119, 651 DOI 10.17487/RFC2119, March 1997, 652 . 654 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 655 Schoenwaelder, Ed., "Structure of Management Information 656 Version 2 (SMIv2)", STD 58, RFC 2578, 657 DOI 10.17487/RFC2578, April 1999, 658 . 660 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 661 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 662 STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 663 . 665 [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. 666 Schoenwaelder, Ed., "Conformance Statements for SMIv2", 667 STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, 668 . 670 [RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of 671 Managed Objects for the Optical Interface Type", RFC 3591, 672 DOI 10.17487/RFC3591, September 2003, 673 . 675 [RFC6205] Otani, T., Ed. and D. Li, Ed., "Generalized Labels for 676 Lambda-Switch-Capable (LSC) Label Switching Routers", 677 RFC 6205, DOI 10.17487/RFC6205, March 2011, 678 . 680 [ITU.G698.2] 681 International Telecommunications Union, "Amplified 682 multichannel dense wavelength division multiplexing 683 applications with single channel optical interfaces", 684 ITU-T Recommendation G.698.2, November 2009. 686 [ITU.G709] 687 International Telecommunications Union, "Interface for the 688 Optical Transport Network (OTN)", ITU-T Recommendation 689 G.709, March 2003. 691 [ITU.G872] 692 International Telecommunications Union, "Architecture of 693 optical transport networks", ITU-T Recommendation G.872, 694 November 2001. 696 [ITU.G798] 697 International Telecommunications Union, "Characteristics 698 of optical transport network hierarchy equipment 699 functional blocks", ITU-T Recommendation G.798, October 700 2010. 702 [ITU.G874] 703 International Telecommunications Union, "Management 704 aspects of optical transport network elements", 705 ITU-T Recommendation G.874, July 2010. 707 [ITU.G874.1] 708 International Telecommunications Union, "Optical transport 709 network (OTN): Protocol-neutral management information 710 model for the network element view", ITU-T Recommendation 711 G.874.1, January 2002. 713 [ITU.G959.1] 714 International Telecommunications Union, "Optical transport 715 network physical layer interfaces", ITU-T Recommendation 716 G.959.1, November 2009. 718 [ITU.G826] 719 International Telecommunications Union, "End-to-end error 720 performance parameters and objectives for international, 721 constant bit-rate digital paths and connections", 722 ITU-T Recommendation G.826, November 2009. 724 [ITU.G8201] 725 International Telecommunications Union, "Error performance 726 parameters and objectives for multi-operator international 727 paths within the Optical Transport Network (OTN)", 728 ITU-T Recommendation G.8201, April 2011. 730 [ITU.G694.1] 731 International Telecommunications Union, "Spectral grids 732 for WDM applications: DWDM frequency grid", 733 ITU-T Recommendation G.694.1, June 2002. 735 [ITU.G7710] 736 International Telecommunications Union, "Common equipment 737 management function requirements", ITU-T Recommendation 738 G.7710, May 2008. 740 11.2. Informative References 742 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 743 "Introduction and Applicability Statements for Internet- 744 Standard Management Framework", RFC 3410, 745 DOI 10.17487/RFC3410, December 2002, 746 . 748 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 749 DOI 10.17487/RFC2629, June 1999, 750 . 752 [RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of 753 MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181, 754 September 2005, . 756 [I-D.kdkgall-ccamp-dwdm-if-mng-ctrl-fwk] 757 Kunze, R., Grammel, G., Beller, D., and G. Galimberti, "A 758 framework for Management and Control of G.698.2 optical 759 interface parameters", draft-kdkgall-ccamp-dwdm-if-mng- 760 ctrl-fwk-00 (work in progress), October 2015. 762 [RFC4054] Strand, J., Ed. and A. Chiu, Ed., "Impairments and Other 763 Constraints on Optical Layer Routing", RFC 4054, 764 DOI 10.17487/RFC4054, May 2005, 765 . 767 Appendix A. Change Log 769 This optional section should be removed before the internet draft is 770 submitted to the IESG for publication as an RFC. 772 Note to RFC Editor: please remove this appendix before publication as 773 an RFC. 775 Appendix B. Open Issues 777 Note to RFC Editor: please remove this appendix before publication as 778 an RFC. 780 Authors' Addresses 782 Gabriele Galimberti (editor) 783 Cisco 784 Via Santa Maria Molgora, 48 c 785 20871 - Vimercate 786 Italy 788 Phone: +390392091462 789 Email: ggalimbe@cisco.com 790 Ruediger Kunze (editor) 791 Deutsche Telekom 792 Dddd, xx 793 Berlin 794 Germany 796 Phone: +49xxxxxxxxxx 797 Email: RKunze@telekom.de 799 Kam Lam (editor) 800 Alcatel-Lucent 801 USA 803 Phone: +1 732 331 3476 804 Email: kam.lam@alcatel-lucent.com 806 Dharini Hiremagalur (editor) 807 Juniper 808 1194 N Mathilda Avenue 809 Sunnyvale - 94089 California 810 USA 812 Email: dharinih@juniper.net 814 Gert Grammel (editor) 815 Juniper 816 Oskar-Schlemmer Str. 15 817 80807 Muenchen 818 Germany 820 Phone: +49 1725186386 821 Email: ggrammel@juniper.net 823 Luyuan Fang (editor) 824 Microsoft 825 5600 148th Ave NE 826 Redmond, WA 98502 827 USA 829 Email: lufang@microsoft.com 830 Gary Ratterree (editor) 831 Microsoft 832 5600 148th Ave NE 833 Redmond, WA 98502 834 USA 836 Email: gratt@microsoft.com