idnits 2.17.1 draft-hares-netconf-i2rs-restconf-01.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 163 has weird spacing: '...tastore are c...' == Line 169 has weird spacing: '...tastore is a ...' == Line 217 has weird spacing: '...ges win the p...' == Line 235 has weird spacing: '... update the p...' == Line 378 has weird spacing: '...ll-back an ep...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 13, 2017) is 2594 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC8040' is mentioned on line 583, but not defined == Missing Reference: 'RFC6241' is mentioned on line 513, but not defined == Missing Reference: 'RFC7921' is mentioned on line 555, but not defined == Missing Reference: 'RFC2119' is mentioned on line 485, but not defined == Missing Reference: 'RFC7920' is mentioned on line 550, but not defined == Missing Reference: 'RFC7922' is mentioned on line 560, but not defined == Missing Reference: 'RFC7923' is mentioned on line 565, but not defined == Missing Reference: 'RFC7895' is mentioned on line 546, but not defined ** Obsolete undefined reference: RFC 7895 (Obsoleted by RFC 8525) == Missing Reference: 'RFC8072' is mentioned on line 587, but not defined == Missing Reference: 'RFC5424' is mentioned on line 504, but not defined == Missing Reference: 'RFC4107' is mentioned on line 490, but not defined == Missing Reference: 'RFC4960' is mentioned on line 494, but not defined ** Obsolete undefined reference: RFC 4960 (Obsoleted by RFC 9260) == Missing Reference: 'RFC5339' is mentioned on line 498, but not defined == Missing Reference: 'RFC6020' is mentioned on line 508, but not defined == Missing Reference: 'RFC6242' is mentioned on line 518, but not defined == Missing Reference: 'RFC6244' is mentioned on line 522, but not defined == Missing Reference: 'RFC6536' is mentioned on line 526, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC7158' is mentioned on line 531, but not defined ** Obsolete undefined reference: RFC 7158 (Obsoleted by RFC 7159) == Missing Reference: 'RFC7589' is mentioned on line 535, but not defined == Missing Reference: 'RFC7803' is mentioned on line 541, but not defined == Missing Reference: 'RFC7950' is mentioned on line 570, but not defined == Missing Reference: 'RFC7952' is mentioned on line 574, but not defined == Missing Reference: 'RFC7958' is mentioned on line 578, but not defined == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 620, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-yang-l3-topology' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-call-home' is defined on line 636, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-restconf' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-rfc5277bis' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-tls-client-server' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-yang-patch' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-zerotouch' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-schema-mount' is defined on line 696, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-rib-data-model-07 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-10 == Outdated reference: A later version (-06) exists of draft-ietf-i2rs-security-environment-reqs-04 == Outdated reference: A later version (-16) exists of draft-ietf-i2rs-yang-l3-topology-08 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-00 == Outdated reference: A later version (-22) exists of draft-ietf-netconf-netconf-event-notifications-01 == Outdated reference: A later version (-15) exists of draft-ietf-netconf-restconf-notif-02 == Outdated reference: A later version (-41) exists of draft-ietf-netconf-tls-client-server-01 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-05 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-13 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-01 == Outdated reference: A later version (-12) exists of draft-ietf-netmod-schema-mount-04 == Outdated reference: A later version (-32) exists of draft-ietf-netmod-syslog-model-13 Summary: 4 errors (**), 0 flaws (~~), 53 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS working group S. Hares 3 Internet-Draft Huawei 4 Intended status: Informational A. Dass 5 Expires: September 14, 2017 Ericsson 6 March 13, 2017 8 RESTCONF Changes to Support I2RS Protocol 9 draft-hares-netconf-i2rs-restconf-01.txt 11 Abstract 13 This document describes two RESTCONF optional capabilities (control 14 plane datastore capability, ephemeral state capabilities) that are 15 needed to support the I2RS protocol needs. The I2RS protocol 16 requirese an ephemeral control plane datastore. as control plane 17 datastores. 19 The purpose of this draft is to kick-start the discussions with 20 NETCONF on these two capabilities. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 14, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Background on I2RS . . . . . . . . . . . . . . . . . . . 3 58 1.2. Structure of draft . . . . . . . . . . . . . . . . . . . 3 59 2. Definitions and Background on I2RS . . . . . . . . . . . . . 3 60 2.1. IETF Requirements language . . . . . . . . . . . . . . . 3 61 2.2. I2RS Definitions . . . . . . . . . . . . . . . . . . . . 3 62 2.3. Example for operator-applied policy . . . . . . . . . . . 5 63 2.4. I2RS protocol requirements . . . . . . . . . . . . . . . 6 64 3. RESTCONF control plane datastore capability . . . . . . . . . 6 65 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . 7 67 3.3. New Operations . . . . . . . . . . . . . . . . . . . . . 7 68 3.4. Modified Operations . . . . . . . . . . . . . . . . . . . 7 69 4. RESTCONF protocol extensions for the ephemeral datastore . . 8 70 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . 9 72 4.3. Capability identifier . . . . . . . . . . . . . . . . . . 9 73 4.4. New Operations . . . . . . . . . . . . . . . . . . . . . 9 74 4.5. modification to data resources . . . . . . . . . . . . . 9 75 4.6. Modification to existing operations . . . . . . . . . . . 10 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 8.1. Normative References: . . . . . . . . . . . . . . . . . . 11 81 8.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 This a proposal for the following two RESTCONF capabilities to 87 augment RESTCONF [RFC8040] to support the first version of the I2RS 88 protocol: Control plane datstore capability and ephemeral state 89 capability. The yang that supports this proposal is described in 90 [I-D.hares-netmod-i2rs-yang]. This work is based on the datastore 91 definitions in [I-D.ietf-netmod-revised-datastores]. 93 This draft parallels a similar proposal for NETCONF [RFC6241] is 94 described in [I-D.hares-netconf-i2rs-protocol]. The difference is 95 the original design is to embedded the I2RS multi-headed collision 96 resolution in the "control plane data store capability". However 97 RESTCONF has edit-collision capability already which only needs a 98 usage description. Therefore, this document has a I2RS Edit- 99 Collision capability. 101 Caveat: This work is an individual draft (not an I2RS WG effort) 103 1.1. Background on I2RS 105 The I2RS architecture [RFC7921] defines the I2RS interface "a 106 programmatic interface for state transfer in and out of the Internet 107 routing system". The I2RS protocol is a protocol designed to a 108 higher level protocol comprised of a set of existing protocols which 109 have been extended to work together to support a new interface to the 110 routing system. The I2RS protocol is a "reuse" management protocol 111 which creates new management protocols by reusing existing protocols 112 and extending these protocols for new uses, and has been designed to 113 be implemented in phases [RFC7921]. 115 1.2. Structure of draft 117 The structure of this document is: 119 Section 2 provides definitions and background on I2RS work. (If 120 you are familiar with the I2RS architecture and requirements, you 121 can skip this section.) 123 Section 3 describes the RESTCONF control plane datastore 124 capability. 126 Section 4 describes the RESTCONF ephemeral state capabiilty. . 128 2. Definitions and Background on I2RS 130 This section reviews definitions from I2RS architecture, and provides 131 background on I2RS work for the reader. 133 2.1. IETF Requirements language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 2.2. I2RS Definitions 141 The I2RS architecture [RFC7921] defines the following terms: 143 ephemeral data: is data which does not persist across a reboot 144 (software or hardware) or a power on/off condition. Ephemeral 145 data can be configured data or data recorded from operations of 146 the router. Ephemeral configuration data also has the property 147 that a system cannot roll back to a previous ephemeral 148 configuration state. (See [RFC7921] for an architectural 149 overview, [I-D.ietf-i2rs-ephemeral-state] for requirements, and 150 [I-D.ietf-netmod-revised-datastores] for discussion of how the 151 ephemeral datastore as a control plane datastore interacts with 152 intended datstore and dynamic configuration protocols to form the 153 applied datastore". 155 local configuration: is the data on a routing system which does 156 persist across a reboot (software or hardware) and a power on/off 157 condition. Local configuration has the ability to roll back to a 158 pervious configuration state. Local configuration is defined as 159 the intended datastore [I-D.ietf-netmod-revised-datastores] which 160 is modified by dynamic configuration protocols (such as DHCP) and 161 the I2RS ephemeral data store 163 dynamic configuration protocols datastore are configuration 164 protocols such as DHCP that interact with the intended datastore 165 (which does persist across a reboot (software or hardware) power 166 on/off condition), and the I2RS ephemeral state control plane 167 datastore. 169 control plane protocols datastore is a datastore which is loaded by 170 control plane protocols (e.g. I2RS protocol) rather than system 171 configuration protocols. (see 172 [I-D.ietf-netmod-revised-datastores]). 174 operator-applied policy: is a policy that an operator sets that 175 determines how the ephemeral datastore as a control plane data 176 store interacts with applied datastore (as defined in 177 [I-D.ietf-netmod-revised-datastores]). This operator policy 178 consists of policy knobs that the operator sets to determine how 179 the I2RS agent control plane ephemeral state datastore will 180 interact with the intended configuration datastor and the dynamic 181 configuration protocol datastore. Three policy knobs could be 182 used to implement this policy: 184 * policy knob 1: I2RS Ephemeral control-plane datastore takes 185 takes precedence over the intended datastore in the routing 186 protocols. 188 * policy knob 2: Updated intended configuration datastore takes 189 precedence over the I2RS ephemeral control-plane data store in 190 the routing protocols 192 * policy knob 3: Ephemeral control plane datastore takes 193 precedence over any other dynamic configuration protocols 194 datastore. 196 2.3. Example for operator-applied policy 198 An practical example for three states of the operator-applied policy 199 may help the reader understand the concept. Consider the following 200 three desired outcomes with their policy knob states: 202 Monitoring Features only The policy knob settings are: 204 Policy knob 1=false, 206 policy knob 2=true, 208 Policy knob 3=false, 210 Action: I2RS protocol software feature is installed, but the 211 operator does not want the I2RS ephemarl datastore to take 212 precedence (that is be used) on any variables in the applied 213 configuration datastore. This policy set might be valid if I2RS 214 is only suppose to monitor data on this node through newly defined 215 parameters. 217 I2RS Agent Changes win the policy knob settings would be: 219 Policy knob 1=true, 221 policy knob 2=false, 223 Policy knob 3=false, 225 Action: This is the normal case for the I2RS Agent where the 226 ephemeral control-plane datastore takes precedence over the 227 intended configuration datastore and dynamic configuration 228 datastores. The values from the I2RS ephemearl datastore are used 229 rather than the intended configuration datastore and the dynamic 230 configuration protocol datastore. When the ephemeral data is 231 removed by the I2RS agent, the dyanmic configuration datastore and 232 the intended configuration datastore state is restored, combined 233 and passed to the routing protocols for application. 235 Just change until next configuration update the policy knob settings 236 would be: 238 Policy knob 1=true, 239 policy knob 2=true, 241 Policy knob 3=false, 243 Action: This case can occur if the I2RS Client write to the 244 ephemeral control plane data store is only suppose to take 245 precedence until the next configuration cycle from a centralized 246 system. Suppose the local configuration is get by the centralized 247 system at 11:00pm each night. The I2RS Client writes temporary 248 changes to the routing system via the I2RS agent ephemeral write. 249 At 11:00pm, the local configuration update overwrite the 250 ephemeral. The I2RS Agent notifies the I2RS Client which is 251 tracking which of the ephemeral changes are being overwritten. 253 2.4. I2RS protocol requirements 255 The requirements for the I2RS protocol are defined in the following 256 documents: 258 o I2RS Problem Statement [RFC7920], 260 o I2RS Architecture [RFC7921], 262 o I2RS Traceability [RFC7922], 264 o Publication and Subscription [RFC7923], 266 o I2RS Ephemeral State Requrements, , 267 [I-D.ietf-i2rs-ephemeral-state] 269 o I2RS Protocol Security Requirements, 270 [I-D.ietf-i2rs-protocol-security-requirements] 272 The Interface to the routing System (I2RS) creates a new capability 273 for the routing systems, and with greater capaiblities come a greater 274 need for security. The requirements for a secure environment for 275 I2RS is described in [I-D.ietf-i2rs-security-environment-reqs]. 277 3. RESTCONF control plane datastore capability 279 capability-name: control-plane datastore 281 3.1. Overview 283 The :control-plane datastore capability enables the RESTCONF to 284 support the following: 286 o API resource that is {+restconf/cp-data} - the storage of control 287 plane datastore's configuration that includes configuration 288 ({+restconf/cp-data/config}) and operational state specific to the 289 control plane datastore ({+restconf/cp-data/opstate}). 291 o It also includes the ability to have the applied datastore and the 292 opstate datatstore (per [I-D.ietf-netmod-revised-datastores]. 294 3.2. Dependencies 296 This protocol strawman utilizes the following existing proposed 297 features for NETCONF and RESTCONF 299 o RESTCONF [RFC8040]. 301 o Module library [RFC7895], 303 o RESTCONF Patch Media Type [RFC8072], 305 o NETCONF Support for event notifications 306 [I-D.ietf-netconf-netconf-event-notifications], 308 o Publication/Subscription via Push [I-D.ietf-netconf-yang-push], 310 o NETCONF and HTTP Transport for Event Notivications 311 [I-D.ietf-netconf-restconf-notif], 313 o Publication/Subscription via Push [I-D.ietf-netconf-yang-push], 315 o syslog yang module (both [RFC5424] and 316 [I-D.ietf-netmod-syslog-model] 318 3.3. New Operations 320 none 322 3.4. Modified Operations 324 All RESTCONF methods (OPTIONS, HEAD, GET, POST, PT, PATCH, DELETE) 325 need to work in the control plane datastores. config=TRUE data, and 326 where appropriate config=FALSE data. 328 Editor's Note: Amazingly, RESTCONF is almost ready for the control 329 plane data. The authors understanding of the I2RS protocol needs is 330 why. The best situation is to ask the RESTCONF authors for help 331 specifying what needs to change for the RESTCONF to allow references 332 to datastore. 334 4. RESTCONF protocol extensions for the ephemeral datastore 336 capability-name: ephemeral-state 338 4.1. Overview 340 This capability defines the RESTCONF protocol extensions for control 341 plane protocols that support control plane data stores with ephemeral 342 data. 344 Ephemeral state is not unique to I2RS work. 346 The ephemeral capability is the ability to support control plane 347 datastores which are entirely ephemeral or have ephemeral state 348 modules, or ephemeral statements within objects in a modules. These 349 objects can be configuration state (config=TRUE) or operational state 350 (config=FALSE). 352 Ephemeral state in datastores, ephemeral modules or ephemeral objects 353 within a module have one key characteristics: the data does not 354 persist across reboots. The ephemeral configuration state must be 355 restored by a client, and the operational state will need to be 356 regenerated. 358 The entire requirements for ephemeral state for the I2RS control 359 plane protocol are listed in [I-D.ietf-i2rs-ephemeral-state]. 360 Compared to RESTCONF functionality there are 4 groups of additional 361 changes: 363 Constraints The ability to enforce the constraints for references 364 (to/from) the {+restconf/data} datastore, and a {+restconf/cp- 365 data} control plane datastore. ((see Ephemeral-REQ-02, Ephemeral- 366 REQ-03, and Ephemeral-REQ-04 in [I-D.ietf-i2rs-ephemeral-state]). 367 The "validation" yang statement in [I-D.hares-netmod-i2rs-yang] 368 could encode specific validation for the ephemeral case per 369 datatstore or per object. [Editor's note: Aid is needed from 370 NETCONF authors to determine the best way to enforce the 371 constraints.] 373 Library Tracking of Epheemral Yang modules must identify Yang 374 objects (modules, submodules or objects within yang modules which 375 are ephemeral and augment other nodes) and allow an 376 "ephemeral=TRUE" feature. 378 Roll-back an ephemeral node cannot roll-back to its previous value, 380 4.2. Dependencies 382 The ephemeral capabilities have the following dependencies: 384 o Yang modules must support the following: 386 * identifying datastores, modules, and objects as ephemeral. 387 (ephemeral=True) 389 * Albility to have control plane datastores which are ephemeral. 391 o The following features must be supported by RESTCONF 393 * Module library [RFC7895], 395 * RESTCONF Protocol [RFC8040], 397 * RESTCONF Patch Media Type [RFC8072], 399 * NETCONF Support for event notifications 400 [I-D.ietf-netconf-netconf-event-notifications], 402 * Publication/Subscription via Push [I-D.ietf-netconf-yang-push], 404 * NETCONF and HTTP Transport for Event Notivications 405 [I-D.ietf-netconf-restconf-notif], 407 * Subsribing to Yang datastore push updates 408 [I-D.ietf-netconf-yang-push], 410 4.3. Capability identifier 412 The ephemeral-datastore capability is identified by the following 413 capability string: ephemeral (TBD URI) 415 4.4. New Operations 417 none 419 4.5. modification to data resources 421 RESTCONF must be able to support the ephemeral data in a control 422 plane datastore 424 RESTCONF library functions must be able to store an indication that a 425 data module has ephemeral state. 427 4.6. Modification to existing operations 429 The current operations in RESTCONF are: OPTIONS, HEAD, GET, POST, 430 PUT, PATCH, and DELETE. 432 Editor's note: From here is not solutions but a list of features to 433 discuss with the RESTCONF team. 435 The operations must support the following things about ephemeral The 436 ephemeral data store has the following general qualities: 438 1. The ephemeral datastore is never locked. (RESTCONF does not use 439 a locking mechanism.) 441 2. The ephemeral portion of the intended configuration, applied 442 state, and derived state does not persist over a reboot, 444 3. an ephemeral node cannot roll-back to its previous value, 446 4. Since ephemeral data store is just data that does not presist 447 over a reboot, then in theory any node or group of nodes in a 448 YANG data model could be ephemeral. The YANG data module must 449 indicate what portion of the data model (if any) is ephemeral. 451 * A YANG data module could be all ephemeral (e.g. 452 [I-D.ietf-i2rs-rib-data-model]) with no directly associated 453 configuration models, 455 * A YANG model could be all ephemeral but associated with a 456 configuration model 458 * or a single data node or data tree could be made ephemeral. 460 5. The management protocol (NETCONF/RESTCONF) needs to signal which 461 poritons of a data model(node, tree, or data model) are ephemeral 462 in the module library [RFC7895]. 464 5. IANA Considerations 466 This is a protocol strawman - nothing is going to IANA. 468 6. Security Considerations 470 The security requirements for the I2RS protocol are covered in 471 [I-D.ietf-i2rs-protocol-security-requirements]. The security 472 environment the I2RS protocol is covered in 473 [I-D.ietf-i2rs-security-environment-reqs]. Any person implementing 474 or deploying the I2RS protocol should consider both security 475 requirements. 477 7. Acknowledgements 479 TBD 481 8. References 483 8.1. Normative References: 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, 487 DOI 10.17487/RFC2119, March 1997, 488 . 490 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 491 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 492 June 2005, . 494 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 495 RFC 4960, DOI 10.17487/RFC4960, September 2007, 496 . 498 [RFC5339] Le Roux, JL., Ed. and D. Papadimitriou, Ed., "Evaluation 499 of Existing GMPLS Protocols against Multi-Layer and Multi- 500 Region Networks (MLN/MRN)", RFC 5339, 501 DOI 10.17487/RFC5339, September 2008, 502 . 504 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 505 DOI 10.17487/RFC5424, March 2009, 506 . 508 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 509 the Network Configuration Protocol (NETCONF)", RFC 6020, 510 DOI 10.17487/RFC6020, October 2010, 511 . 513 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 514 and A. Bierman, Ed., "Network Configuration Protocol 515 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 516 . 518 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 519 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 520 . 522 [RFC6244] Shafer, P., "An Architecture for Network Management Using 523 NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 524 2011, . 526 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 527 Protocol (NETCONF) Access Control Model", RFC 6536, 528 DOI 10.17487/RFC6536, March 2012, 529 . 531 [RFC7158] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 532 Interchange Format", RFC 7158, DOI 10.17487/RFC7158, March 533 2014, . 535 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 536 NETCONF Protocol over Transport Layer Security (TLS) with 537 Mutual X.509 Authentication", RFC 7589, 538 DOI 10.17487/RFC7589, June 2015, 539 . 541 [RFC7803] Leiba, B., "Changing the Registration Policy for the 542 NETCONF Capability URNs Registry", BCP 203, RFC 7803, 543 DOI 10.17487/RFC7803, February 2016, 544 . 546 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 547 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 548 . 550 [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem 551 Statement for the Interface to the Routing System", 552 RFC 7920, DOI 10.17487/RFC7920, June 2016, 553 . 555 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 556 Nadeau, "An Architecture for the Interface to the Routing 557 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 558 . 560 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 561 the Routing System (I2RS) Traceability: Framework and 562 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 563 2016, . 565 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 566 for Subscription to YANG Datastores", RFC 7923, 567 DOI 10.17487/RFC7923, June 2016, 568 . 570 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 571 RFC 7950, DOI 10.17487/RFC7950, August 2016, 572 . 574 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 575 RFC 7952, DOI 10.17487/RFC7952, August 2016, 576 . 578 [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman, 579 "DNSSEC Trust Anchor Publication for the Root Zone", 580 RFC 7958, DOI 10.17487/RFC7958, August 2016, 581 . 583 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 584 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 585 . 587 [RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch 588 Media Type", RFC 8072, DOI 10.17487/RFC8072, February 589 2017, . 591 8.2. Informative References 593 [I-D.hares-netconf-i2rs-protocol] 594 Hares, S. and a. amit.dass@ericsson.com, "NETCONF Changes 595 to Support I2RS Protocol", draft-hares-netconf-i2rs- 596 protocol-00 (work in progress), November 2016. 598 [I-D.hares-netmod-i2rs-yang] 599 Hares, S. and a. amit.dass@ericsson.com, "Yang for I2RS 600 Protocol", draft-hares-netmod-i2rs-yang-04 (work in 601 progress), March 2017. 603 [I-D.ietf-i2rs-ephemeral-state] 604 Haas, J. and S. Hares, "I2RS Ephemeral State 605 Requirements", draft-ietf-i2rs-ephemeral-state-23 (work in 606 progress), November 2016. 608 [I-D.ietf-i2rs-protocol-security-requirements] 609 Hares, S., Migault, D., and J. Halpern, "I2RS Security 610 Related Requirements", draft-ietf-i2rs-protocol-security- 611 requirements-17 (work in progress), September 2016. 613 [I-D.ietf-i2rs-rib-data-model] 614 Wang, L., Ananthakrishnan, H., Chen, M., 615 amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A 616 YANG Data Model for Routing Information Base (RIB)", 617 draft-ietf-i2rs-rib-data-model-07 (work in progress), 618 January 2017. 620 [I-D.ietf-i2rs-rib-info-model] 621 Bahadur, N., Kini, S., and J. Medved, "Routing Information 622 Base Info Model", draft-ietf-i2rs-rib-info-model-10 (work 623 in progress), December 2016. 625 [I-D.ietf-i2rs-security-environment-reqs] 626 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 627 Security Requirements", draft-ietf-i2rs-security- 628 environment-reqs-04 (work in progress), March 2017. 630 [I-D.ietf-i2rs-yang-l3-topology] 631 Clemm, A., Medved, J., Varga, R., Liu, X., 632 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 633 for Layer 3 Topologies", draft-ietf-i2rs-yang- 634 l3-topology-08 (work in progress), January 2017. 636 [I-D.ietf-netconf-call-home] 637 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 638 draft-ietf-netconf-call-home-17 (work in progress), 639 December 2015. 641 [I-D.ietf-netconf-keystore] 642 Watsen, K. and G. Wu, "Keystore Model", draft-ietf- 643 netconf-keystore-00 (work in progress), October 2016. 645 [I-D.ietf-netconf-netconf-event-notifications] 646 Prieto, A., Clemm, A., Voit, E., Nilsen-Nygaard, E., 647 Tripathy, A., Chisholm, S., and H. Trevino, "NETCONF 648 Support for Event Notifications", draft-ietf-netconf- 649 netconf-event-notifications-01 (work in progress), October 650 2016. 652 [I-D.ietf-netconf-restconf] 653 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 654 Protocol", draft-ietf-netconf-restconf-18 (work in 655 progress), October 2016. 657 [I-D.ietf-netconf-restconf-notif] 658 Voit, E., Prieto, A., Tripathy, A., Nilsen-Nygaard, E., 659 Clemm, A., and A. Bierman, "Restconf and HTTP Transport 660 for Event Notifications", draft-ietf-netconf-restconf- 661 notif-02 (work in progress), March 2017. 663 [I-D.ietf-netconf-rfc5277bis] 664 Clemm, A., Prieto, A., Voit, E., Nilsen-Nygaard, E., 665 Tripathy, A., Chisholm, S., and H. Trevino, "Subscribing 666 to Event Notifications", draft-ietf-netconf-rfc5277bis-01 667 (work in progress), October 2016. 669 [I-D.ietf-netconf-tls-client-server] 670 Watsen, K., "TLS Client and Server Models", draft-ietf- 671 netconf-tls-client-server-01 (work in progress), November 672 2016. 674 [I-D.ietf-netconf-yang-patch] 675 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch 676 Media Type", draft-ietf-netconf-yang-patch-14 (work in 677 progress), November 2016. 679 [I-D.ietf-netconf-yang-push] 680 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 681 Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to 682 YANG datastore push updates", draft-ietf-netconf-yang- 683 push-05 (work in progress), March 2017. 685 [I-D.ietf-netconf-zerotouch] 686 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning 687 for NETCONF or RESTCONF based Management", draft-ietf- 688 netconf-zerotouch-13 (work in progress), March 2017. 690 [I-D.ietf-netmod-revised-datastores] 691 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 692 and R. Wilton, "Network Management Datastore 693 Architecture", draft-ietf-netmod-revised-datastores-01 694 (work in progress), March 2017. 696 [I-D.ietf-netmod-schema-mount] 697 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 698 ietf-netmod-schema-mount-04 (work in progress), March 699 2017. 701 [I-D.ietf-netmod-syslog-model] 702 Wildes, C. and K. Koushik, "A YANG Data Model for Syslog 703 Configuration", draft-ietf-netmod-syslog-model-13 (work in 704 progress), March 2017. 706 Authors' Addresses 708 Susan Hares 709 Huawei 710 Saline 711 US 713 Email: shares@ndzh.com 715 Amit Daas 716 Ericsson 718 Email: amit.dass@ericsson.com