idnits 2.17.1 draft-hares-netconf-i2rs-restconf-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 157 has weird spacing: '...tastore are c...' == Line 163 has weird spacing: '...tastore is a ...' == Line 320 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 29, 2017) is 2585 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC8040' is mentioned on line 502, but not defined == Missing Reference: 'RFC6241' is mentioned on line 432, but not defined == Missing Reference: 'RFC7921' is mentioned on line 474, but not defined == Missing Reference: 'RFC2119' is mentioned on line 404, but not defined == Missing Reference: 'RFC7920' is mentioned on line 469, but not defined == Missing Reference: 'RFC7922' is mentioned on line 479, but not defined == Missing Reference: 'RFC7923' is mentioned on line 484, but not defined == Missing Reference: 'RFC7895' is mentioned on line 465, but not defined ** Obsolete undefined reference: RFC 7895 (Obsoleted by RFC 8525) == Missing Reference: 'RFC8072' is mentioned on line 506, but not defined == Missing Reference: 'RFC5424' is mentioned on line 423, but not defined == Missing Reference: 'RFC4107' is mentioned on line 409, but not defined == Missing Reference: 'RFC4960' is mentioned on line 413, but not defined ** Obsolete undefined reference: RFC 4960 (Obsoleted by RFC 9260) == Missing Reference: 'RFC5339' is mentioned on line 417, but not defined == Missing Reference: 'RFC6020' is mentioned on line 427, but not defined == Missing Reference: 'RFC6242' is mentioned on line 437, but not defined == Missing Reference: 'RFC6244' is mentioned on line 441, but not defined == Missing Reference: 'RFC6536' is mentioned on line 445, but not defined ** Obsolete undefined reference: RFC 6536 (Obsoleted by RFC 8341) == Missing Reference: 'RFC7158' is mentioned on line 450, but not defined ** Obsolete undefined reference: RFC 7158 (Obsoleted by RFC 7159) == Missing Reference: 'RFC7589' is mentioned on line 454, but not defined == Missing Reference: 'RFC7803' is mentioned on line 460, but not defined == Missing Reference: 'RFC7950' is mentioned on line 489, but not defined == Missing Reference: 'RFC7952' is mentioned on line 493, but not defined == Missing Reference: 'RFC7958' is mentioned on line 497, but not defined == Unused Reference: 'I-D.ietf-i2rs-rib-data-model' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-rib-info-model' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-yang-l3-topology' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-call-home' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line 560, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-restconf' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-rfc5277bis' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-tls-client-server' is defined on line 588, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-yang-patch' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-zerotouch' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-schema-mount' is defined on line 615, 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-05 == 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-01 == 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-02 == 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-14 Summary: 4 errors (**), 0 flaws (~~), 52 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 30, 2017 Ericsson 6 March 29, 2017 8 RESTCONF Changes to Support I2RS Protocol 9 draft-hares-netconf-i2rs-restconf-02.txt 11 Abstract 13 This document describes two RESTCONF optional capabilities (i2rs- 14 control plane capability, ephemeral state capabilities) that are 15 needed to support the I2RS protocol needs. 17 The purpose of this draft is to kick-start the discussions with I2RS 18 Working Group and NETCONF WG on these two capabilities. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 30, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Background on I2RS . . . . . . . . . . . . . . . . . . . 3 56 1.2. Structure of draft . . . . . . . . . . . . . . . . . . . 3 57 2. Definitions and Background on I2RS . . . . . . . . . . . . . 3 58 2.1. IETF Requirements language . . . . . . . . . . . . . . . 3 59 2.2. I2RS Definitions . . . . . . . . . . . . . . . . . . . . 3 60 2.3. I2RS protocol requirements . . . . . . . . . . . . . . . 5 61 3. RESTCONF control plane datastore capability . . . . . . . . . 5 62 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3. New Operations . . . . . . . . . . . . . . . . . . . . . 6 65 3.4. Modified Operations . . . . . . . . . . . . . . . . . . . 6 66 4. RESTCONF protocol extensions for the ephemeral datastore . . 6 67 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . 7 69 4.3. Capability identifier . . . . . . . . . . . . . . . . . . 8 70 4.4. New Operations . . . . . . . . . . . . . . . . . . . . . 8 71 4.5. Modification to data resources . . . . . . . . . . . . . 8 72 4.6. Modification to existing operations . . . . . . . . . . . 8 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 8.1. Normative References: . . . . . . . . . . . . . . . . . . 9 78 8.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 81 1. Introduction 83 This a proposal for the following two RESTCONF capabilities to 84 augment RESTCONF [RFC8040] to support the first version of the I2RS 85 protocol: Control plane datstore capability and ephemeral state 86 capability. The yang that supports this proposal is described in 87 [I-D.hares-netmod-i2rs-yang]. This work is based on the datastore 88 definitions in [I-D.ietf-netmod-revised-datastores]. 90 This draft parallels a similar proposal for NETCONF [RFC6241] is 91 described in [I-D.hares-netconf-i2rs-protocol]. One difference 92 between the proposed capabilities for i2rs control-plane capability 93 additions to NETCONF and the proposed capabilities for i2rs control- 94 plane for RESTCONF is write-collection. RESTCONF has edit-collision 95 capability already which only needs a usage description. 97 1.1. Background on I2RS 99 The I2RS architecture [RFC7921] defines the I2RS interface "a 100 programmatic interface for state transfer in and out of the Internet 101 routing system". The I2RS protocol is a protocol designed to a 102 higher level protocol comprised of a set of existing protocols which 103 have been extended to work together to support a new interface to the 104 routing system. The I2RS protocol is a "reuse" management protocol 105 which creates new management protocols by reusing existing protocols 106 and extending these protocols for new uses, and has been designed to 107 be implemented in phases [RFC7921]. 109 1.2. Structure of draft 111 The structure of this document is: 113 Section 2 provides definitions and background on I2RS work. (If 114 you are familiar with the I2RS architecture and requirements, you 115 can skip this section.) 117 Section 3 describes the RESTCONF control plane datastore 118 capability. 120 Section 4 describes the RESTCONF ephemeral state capabiilty. . 122 2. Definitions and Background on I2RS 124 This section reviews definitions from I2RS architecture, and provides 125 background on I2RS work for the reader. 127 2.1. IETF Requirements language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 2.2. I2RS Definitions 135 The I2RS architecture [RFC7921] defines the following terms: 137 ephemeral data: is data which does not persist across a reboot 138 (software or hardware) or a power on/off condition. Ephemeral 139 data can be configured data or data recorded from operations of 140 the router. Ephemeral configuration data also has the property 141 that a system cannot roll back to a previous ephemeral 142 configuration state. (See [RFC7921] for an architectural 143 overview, [I-D.ietf-i2rs-ephemeral-state] for requirements, and 144 [I-D.ietf-netmod-revised-datastores] for discussion of how the 145 ephemeral datastore as a control plane datastore interacts with 146 intended datstore and dynamic configuration protocols to form the 147 applied datastore". 149 local configuration: is the data on a routing system which does 150 persist across a reboot (software or hardware) and a power on/off 151 condition. Local configuration has the ability to roll back to a 152 pervious configuration state. Local configuration is defined as 153 the intended datastore [I-D.ietf-netmod-revised-datastores] which 154 is modified by dynamic configuration protocols (such as DHCP) and 155 the I2RS ephemeral data store 157 dynamic configuration protocols datastore are configuration 158 protocols such as DHCP that interact with the intended datastore 159 (which does persist across a reboot (software or hardware) power 160 on/off condition), and the I2RS ephemeral state control plane 161 datastore. 163 control plane protocols datastore is a datastore which is loaded by 164 control plane protocols (e.g. I2RS protocol) rather than system 165 configuration protocols. (see 166 [I-D.ietf-netmod-revised-datastores]). 168 operator-applied policy: is a policy that an operator sets that 169 determines how the ephemeral datastore as a control plane data 170 store interacts with applied datastore (as defined in 171 [I-D.ietf-netmod-revised-datastores]). This operator policy 172 consists of policy knobs that the operator sets to determine how 173 the I2RS agent control plane ephemeral state datastore will 174 interact with the intended configuration datastor and the dynamic 175 configuration protocol datastore. Three policy knobs could be 176 used to implement this policy: 178 * policy knob 1: I2RS Ephemeral control-plane datastore takes 179 takes precedence over the intended datastore in the routing 180 protocols. 182 * policy knob 2: Updated intended configuration datastore takes 183 precedence over the I2RS ephemeral control-plane data store in 184 the routing protocols 186 * policy knob 3: Ephemeral control plane datastore takes 187 precedence over any other dynamic configuration protocols 188 datastore. 190 2.3. I2RS protocol requirements 192 The requirements for the I2RS protocol are defined in the following 193 documents: 195 o I2RS Problem Statement [RFC7920], 197 o I2RS Architecture [RFC7921], 199 o I2RS Traceability [RFC7922], 201 o Publication and Subscription [RFC7923], 203 o I2RS Ephemeral State Requrements, , 204 [I-D.ietf-i2rs-ephemeral-state] 206 o I2RS Protocol Security Requirements, 207 [I-D.ietf-i2rs-protocol-security-requirements] 209 The Interface to the routing System (I2RS) creates a new capability 210 for the routing systems, and with greater capaiblities come a greater 211 need for security. The requirements for a secure environment for 212 I2RS is described in [I-D.ietf-i2rs-security-environment-reqs]. 214 3. RESTCONF control plane datastore capability 216 capability-name: i2rs-control-plane 218 3.1. Overview 220 The i2rs-control-plane datastore capability enables the RESTCONF to 221 support the following dynamic control plane datastore. 223 o API resource that is {+restconf}/datastore//data/ 224 and operational state specific to the control plane datastore 225 ({+restconf/cp-data/opstate}). 227 o It also includes the ability to have the applied datastore and the 228 opstate datatstore (per [I-D.ietf-netmod-revised-datastores]) with 229 the ability to return meta-data with the following information: 231 * Entity-Tag encoding of or any portion of 232 the filter. 234 * "with defaults" 236 * "with validation" - Yang specified validation (Unclear if this 237 is the best way for validation.) 239 Ability to provide read access for the configuration datstore 241 Ability to provide read access for other dynamic datastores 243 3.2. Dependencies 245 This protocol strawman utilizes the following existing proposed 246 features for NETCONF and RESTCONF 248 o RESTCONF [RFC8040]. 250 o Module library [RFC7895], 252 o RESTCONF Patch Media Type [RFC8072], 254 o NETCONF Support for event notifications 255 [I-D.ietf-netconf-netconf-event-notifications], 257 o Publication/Subscription via Push [I-D.ietf-netconf-yang-push], 259 o NETCONF and HTTP Transport for Event Notivications 260 [I-D.ietf-netconf-restconf-notif], 262 o Publication/Subscription via Push [I-D.ietf-netconf-yang-push], 264 o syslog yang module (both [RFC5424] and 265 [I-D.ietf-netmod-syslog-model] 267 3.3. New Operations 269 none 271 3.4. Modified Operations 273 All RESTCONF methods (OPTIONS, HEAD, GET, POST, PT, PATCH, DELETE) 274 need to work in the control plane datastores. config=TRUE data, and 275 where appropriate config=FALSE data. 277 4. RESTCONF protocol extensions for the ephemeral datastore 279 capability-name: ephemeral-state 281 4.1. Overview 283 This capability defines the RESTCONF protocol extensions for control 284 plane protocols that support control plane data stores with ephemeral 285 data. 287 Ephemeral state is not unique to I2RS work. 289 The ephemeral capability is the ability to support a dynamic 290 datastores which are entirely ephemeral or have ephemeral state 291 modules, or ephemeral statements within objects in a modules. These 292 objects can be configuration state (config=TRUE) or operational state 293 (config=FALSE). 295 Ephemeral state in datastores, ephemeral modules or ephemeral objects 296 within a module have one key characteristics: the data does not 297 persist across reboots. The ephemeral configuration state must be 298 restored by a client, and the operational state will need to be 299 regenerated. 301 The entire requirements for ephemeral state for the I2RS control 302 plane protocol are listed in [I-D.ietf-i2rs-ephemeral-state]. 303 Compared to RESTCONF functionality there are 4 groups of additional 304 changes: 306 Constraints The ability to enforce the constraints for get (aka 307 read) references (to/from) the {+restconf/data} datastore, and 308 {+restconf/cp-data} control plane datastore. ((see Ephemeral-REQ- 309 02, Ephemeral-REQ-03, and Ephemeral-REQ-04 in 310 [I-D.ietf-i2rs-ephemeral-state]). The "validation" yang statement 311 in [I-D.hares-netmod-i2rs-yang] could encode specific validation 312 for the ephemeral case per datatstore or per object. [Editor's 313 note: Aid is needed to determine how validation occurs.] 315 Ephemeral in Data Modules Yang modules must identify Yang objects 316 (modules, submodules or objects within yang modules which are 317 ephemeral and augment other nodes) and allow an "ephemeral=TRUE" 318 feature. 320 Roll-back an ephemeral node cannot roll-back to its previous value, 322 4.2. Dependencies 324 The ephemeral capabilities have the following dependencies: 326 o Yang modules must support the following: 328 * identifying datastores, modules, and objects as ephemeral. 329 (ephemeral=True) 331 * Ability to have control plane datastores which are ephemeral. 333 o The following features must be supported by RESTCONF 334 * Module library [RFC7895], 336 * RESTCONF Protocol [RFC8040], 338 * RESTCONF Patch Media Type [RFC8072], 340 * NETCONF Support for event notifications 341 [I-D.ietf-netconf-netconf-event-notifications], 343 * Publication/Subscription via Push [I-D.ietf-netconf-yang-push], 345 * NETCONF and HTTP Transport for Event Notivications 346 [I-D.ietf-netconf-restconf-notif], 348 * Subsribing to Yang datastore push updates 349 [I-D.ietf-netconf-yang-push], 351 4.3. Capability identifier 353 The ephemeral-datastore capability is identified by the following 354 capability string: ephemeral (TBD URI) 356 4.4. New Operations 358 none 360 4.5. Modification to data resources 362 RESTCONF must be able to support the ephemeral data in an an control- 363 plane dynamic datastore. This is any API resource that is 364 {+restconf}/datastore//data/ and operational state 365 specific to the control plane datastore ({+restconf/cp-data/ 366 opstate}). 368 RESTCONF library functions must be able to store an indication that a 369 data module has ephemeral state as meta-data. 371 4.6. Modification to existing operations 373 RESTCONF operations of GET, POST, PUT, PATCH, and DELETE must be able 374 to filter on meta-data with "ephemeral" flag. (Should this be only 375 read). 377 The operations must support the following things about ephemeral. 379 1. The ephemeral does not persist over a reboot, 381 2. an ephemeral node cannot roll-back to its previous value, 383 5. IANA Considerations 385 TBD - 387 6. Security Considerations 389 The security requirements for the I2RS protocol are covered in 390 [I-D.ietf-i2rs-protocol-security-requirements]. The security 391 environment the I2RS protocol is covered in 392 [I-D.ietf-i2rs-security-environment-reqs]. Any person implementing 393 or deploying the I2RS protocol should consider both security 394 requirements. 396 7. Acknowledgements 398 TBD 400 8. References 402 8.1. Normative References: 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, 406 DOI 10.17487/RFC2119, March 1997, 407 . 409 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 410 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 411 June 2005, . 413 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 414 RFC 4960, DOI 10.17487/RFC4960, September 2007, 415 . 417 [RFC5339] Le Roux, JL., Ed. and D. Papadimitriou, Ed., "Evaluation 418 of Existing GMPLS Protocols against Multi-Layer and Multi- 419 Region Networks (MLN/MRN)", RFC 5339, 420 DOI 10.17487/RFC5339, September 2008, 421 . 423 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 424 DOI 10.17487/RFC5424, March 2009, 425 . 427 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 428 the Network Configuration Protocol (NETCONF)", RFC 6020, 429 DOI 10.17487/RFC6020, October 2010, 430 . 432 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 433 and A. Bierman, Ed., "Network Configuration Protocol 434 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 435 . 437 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 438 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 439 . 441 [RFC6244] Shafer, P., "An Architecture for Network Management Using 442 NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 443 2011, . 445 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 446 Protocol (NETCONF) Access Control Model", RFC 6536, 447 DOI 10.17487/RFC6536, March 2012, 448 . 450 [RFC7158] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 451 Interchange Format", RFC 7158, DOI 10.17487/RFC7158, March 452 2014, . 454 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 455 NETCONF Protocol over Transport Layer Security (TLS) with 456 Mutual X.509 Authentication", RFC 7589, 457 DOI 10.17487/RFC7589, June 2015, 458 . 460 [RFC7803] Leiba, B., "Changing the Registration Policy for the 461 NETCONF Capability URNs Registry", BCP 203, RFC 7803, 462 DOI 10.17487/RFC7803, February 2016, 463 . 465 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 466 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 467 . 469 [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem 470 Statement for the Interface to the Routing System", 471 RFC 7920, DOI 10.17487/RFC7920, June 2016, 472 . 474 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 475 Nadeau, "An Architecture for the Interface to the Routing 476 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 477 . 479 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 480 the Routing System (I2RS) Traceability: Framework and 481 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 482 2016, . 484 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 485 for Subscription to YANG Datastores", RFC 7923, 486 DOI 10.17487/RFC7923, June 2016, 487 . 489 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 490 RFC 7950, DOI 10.17487/RFC7950, August 2016, 491 . 493 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 494 RFC 7952, DOI 10.17487/RFC7952, August 2016, 495 . 497 [RFC7958] Abley, J., Schlyter, J., Bailey, G., and P. Hoffman, 498 "DNSSEC Trust Anchor Publication for the Root Zone", 499 RFC 7958, DOI 10.17487/RFC7958, August 2016, 500 . 502 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 503 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 504 . 506 [RFC8072] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch 507 Media Type", RFC 8072, DOI 10.17487/RFC8072, February 508 2017, . 510 8.2. Informative References 512 [I-D.hares-netconf-i2rs-protocol] 513 Hares, S. and a. amit.dass@ericsson.com, "NETCONF Changes 514 to Support I2RS Protocol", draft-hares-netconf-i2rs- 515 protocol-00 (work in progress), November 2016. 517 [I-D.hares-netmod-i2rs-yang] 518 Hares, S. and a. amit.dass@ericsson.com, "Yang for I2RS 519 Protocol", draft-hares-netmod-i2rs-yang-04 (work in 520 progress), March 2017. 522 [I-D.ietf-i2rs-ephemeral-state] 523 Haas, J. and S. Hares, "I2RS Ephemeral State 524 Requirements", draft-ietf-i2rs-ephemeral-state-23 (work in 525 progress), November 2016. 527 [I-D.ietf-i2rs-protocol-security-requirements] 528 Hares, S., Migault, D., and J. Halpern, "I2RS Security 529 Related Requirements", draft-ietf-i2rs-protocol-security- 530 requirements-17 (work in progress), September 2016. 532 [I-D.ietf-i2rs-rib-data-model] 533 Wang, L., Ananthakrishnan, H., Chen, M., 534 amit.dass@ericsson.com, a., Kini, S., and N. Bahadur, "A 535 YANG Data Model for Routing Information Base (RIB)", 536 draft-ietf-i2rs-rib-data-model-07 (work in progress), 537 January 2017. 539 [I-D.ietf-i2rs-rib-info-model] 540 Bahadur, N., Kini, S., and J. Medved, "Routing Information 541 Base Info Model", draft-ietf-i2rs-rib-info-model-10 (work 542 in progress), December 2016. 544 [I-D.ietf-i2rs-security-environment-reqs] 545 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 546 Security Requirements", draft-ietf-i2rs-security- 547 environment-reqs-05 (work in progress), March 2017. 549 [I-D.ietf-i2rs-yang-l3-topology] 550 Clemm, A., Medved, J., Varga, R., Liu, X., 551 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 552 for Layer 3 Topologies", draft-ietf-i2rs-yang- 553 l3-topology-08 (work in progress), January 2017. 555 [I-D.ietf-netconf-call-home] 556 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 557 draft-ietf-netconf-call-home-17 (work in progress), 558 December 2015. 560 [I-D.ietf-netconf-keystore] 561 Watsen, K., "Keystore Model", draft-ietf-netconf- 562 keystore-01 (work in progress), March 2017. 564 [I-D.ietf-netconf-netconf-event-notifications] 565 Prieto, A., Clemm, A., Voit, E., Nilsen-Nygaard, E., 566 Tripathy, A., Chisholm, S., and H. Trevino, "NETCONF 567 Support for Event Notifications", draft-ietf-netconf- 568 netconf-event-notifications-01 (work in progress), October 569 2016. 571 [I-D.ietf-netconf-restconf] 572 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 573 Protocol", draft-ietf-netconf-restconf-18 (work in 574 progress), October 2016. 576 [I-D.ietf-netconf-restconf-notif] 577 Voit, E., Prieto, A., Tripathy, A., Nilsen-Nygaard, E., 578 Clemm, A., and A. Bierman, "Restconf and HTTP Transport 579 for Event Notifications", draft-ietf-netconf-restconf- 580 notif-02 (work in progress), March 2017. 582 [I-D.ietf-netconf-rfc5277bis] 583 Clemm, A., Prieto, A., Voit, E., Nilsen-Nygaard, E., 584 Tripathy, A., Chisholm, S., and H. Trevino, "Subscribing 585 to Event Notifications", draft-ietf-netconf-rfc5277bis-01 586 (work in progress), October 2016. 588 [I-D.ietf-netconf-tls-client-server] 589 Watsen, K. and G. Wu, "TLS Client and Server Models", 590 draft-ietf-netconf-tls-client-server-02 (work in 591 progress), March 2017. 593 [I-D.ietf-netconf-yang-patch] 594 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch 595 Media Type", draft-ietf-netconf-yang-patch-14 (work in 596 progress), November 2016. 598 [I-D.ietf-netconf-yang-push] 599 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 600 Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to 601 YANG datastore push updates", draft-ietf-netconf-yang- 602 push-05 (work in progress), March 2017. 604 [I-D.ietf-netconf-zerotouch] 605 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning 606 for NETCONF or RESTCONF based Management", draft-ietf- 607 netconf-zerotouch-13 (work in progress), March 2017. 609 [I-D.ietf-netmod-revised-datastores] 610 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 611 and R. Wilton, "Network Management Datastore 612 Architecture", draft-ietf-netmod-revised-datastores-01 613 (work in progress), March 2017. 615 [I-D.ietf-netmod-schema-mount] 616 Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft- 617 ietf-netmod-schema-mount-04 (work in progress), March 618 2017. 620 [I-D.ietf-netmod-syslog-model] 621 Wildes, C. and K. Koushik, "A YANG Data Model for Syslog 622 Configuration", draft-ietf-netmod-syslog-model-14 (work in 623 progress), March 2017. 625 Authors' Addresses 627 Susan Hares 628 Huawei 629 Saline 630 US 632 Email: shares@ndzh.com 634 Amit Daas 635 Ericsson 637 Email: amit.dass@ericsson.com