idnits 2.17.1 draft-ietf-i2rs-ephemeral-state-08.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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 9. Ephemeral data stores SHOULD not require support interactions with writable-running, candidate data store, confirmed commit, and a distinct start-up capability, == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 9. Ephemeral data stores SHOULD not require support for interactions with writeable-running, candidate data stores, confirmed commit, and a distinct start-up capability. -- The document date (May 31, 2016) is 2887 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: 'I-D.ietf-i2rs-architecture' is mentioned on line 525, but not defined == Missing Reference: 'RFC6241' is mentioned on line 593, but not defined == Missing Reference: 'I-D.ietf-netconf-restconf' is mentioned on line 557, but not defined == Missing Reference: 'I-D.ietf-i2rs-pub-sub-requirements' is mentioned on line 536, but not defined == Missing Reference: 'I-D.ietf-i2rs-protocol-security-requirements' is mentioned on line 531, but not defined == Missing Reference: 'I-D.ietf-netconf-yang-push' is mentioned on line 577, but not defined == Missing Reference: 'I-D.ietf-netconf-yang-library' is mentioned on line 567, but not defined == Missing Reference: 'I-D.ietf-netconf-call-home' is mentioned on line 552, but not defined == Missing Reference: 'I-D.ietf-netconf-server-model' is mentioned on line 562, but not defined == Missing Reference: 'I-D.ietf-netconf-yang-patch' is mentioned on line 572, but not defined == Missing Reference: 'I-D.ietf-netconf-zerotouch' is mentioned on line 583, but not defined == Missing Reference: 'I-D.ietf-i2rs-security-environment-reqs' is mentioned on line 541, but not defined == Missing Reference: 'I-D.ietf-i2rs-traceability' is mentioned on line 546, but not defined == Missing Reference: 'I-D.ietf-netmod-yang-metadata' is mentioned on line 588, but not defined == Unused Reference: 'RFC6536' is defined on line 615, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-hares-i2rs-protocol-strawman-02 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 19 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS working group J. Haas 3 Internet-Draft Juniper 4 Intended status: Standards Track S. Hares 5 Expires: December 2, 2016 Huawei 6 May 31, 2016 8 I2RS Ephemeral State Requirements 9 draft-ietf-i2rs-ephemeral-state-08 11 Abstract 13 This document covers requests to the NETMOD and NETCONF Working 14 Groups for functionality to support the ephemeral state requirements 15 to implement the I2RS architecture. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 2, 2016. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 2. Review of Requirements from I2RS architecture document . . . 3 54 3. Ephemeral State Requirements . . . . . . . . . . . . . . . . 5 55 3.1. Persistence . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. YANG Features for Ephemeral State for I2RS Protocol version 1 6 59 5. NETCONF Features for Ephemeral State for I2RS Protocol 60 version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 6. RESTCONF Features for Ephemeral State for I2RS Protocol 62 version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Requirements regarding Supporting Multi-Head Control via 64 Client Priority . . . . . . . . . . . . . . . . . . . . . . . 9 65 8. Multiple Message Transactions . . . . . . . . . . . . . . . . 10 66 9. Pub/Sub Requirements Expanded for Ephemeral State . . . . . . 10 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 70 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 13.1. Normative References: . . . . . . . . . . . . . . . . . 12 72 13.2. Informative References . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 The Interface to the Routing System (I2RS) Working Group is chartered 78 with providing architecture and mechanisms to inject into and 79 retrieve information from the routing system. The I2RS Architecture 80 document [I-D.ietf-i2rs-architecture] abstractly documents a number 81 of requirements for implementing the I2RS requirements. Section 2 82 reviews 10 key requirements related to ephemeral state. 84 The I2RS Working Group has chosen to use the YANG data modeling 85 language [RFC6020] as the basis to implement its mechanisms. 87 Additionally, the I2RS Working group has chosen to re-use two 88 existing protocols, NETCONF [RFC6241] and its similar but lighter- 89 weight relative RESTCONF [I-D.ietf-netconf-restconf], as the 90 protocols for carrying I2RS. 92 What does re-use of a protocol mean? Re-use means that while YANG, 93 NETCONF and RESTCONF are a good starting basis for the I2RS protocol, 94 the creation of the I2RS protocol implementations requires that the 95 I2RS requirements 96 1. select features from YANG, NETCONF, and RESTCONF per version of 97 the I2RS protocol (See sections 4, 5, and 6) 99 2. propose additions to YANG, NETCONF, and RESTCONF per version of 100 the I2RS protocol for key functions (ephemeral state, protocol 101 security, publication/subscription service, traceability), 103 3. suggest protocol strawman as ideas for the NETCONF, RESTCONF, and 104 YANG changes. 106 The purpose of these requirements and the suggested protocol straw 107 man is to provide a quick turnaround on creating the I2RS protocol. 109 Support for ephemeral state is I2RS protocol requirement that 110 requires datastore changes (see section 3), Yang additions (see 111 section 4), NETCONF additions (see section 5), and RESTCONF additions 112 (see section 6). 114 Sections 7-9 provide details that expand upon the changes in sections 115 3-6 to clarify requirements discussed by the I2RS and NETCONF working 116 groups. Sections 7 provide additional requirements that detail how 117 write-conflicts should be resolved if two I2RS client write the same 118 data. Section 8 provides an additional requirement that details on 119 I2RS support of multiple message transactions. Section 9 highlights 120 two requirements in the I2RS publication/subscription requirements 121 [I-D.ietf-i2rs-pub-sub-requirements] that must be expanded for 122 ephemeral state. 124 1.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 2. Review of Requirements from I2RS architecture document 132 The I2RS architecture defines important high-level requirements for 133 the I2RS protocol. The following are ten requirements that 134 [I-D.ietf-i2rs-architecture] contains which provide context for the 135 ephemeral data state requirements given in sections 3-8: 137 1. The I2RS protocol SHOULD support highly reliable notifications 138 (but not perfectly reliable notifications) from an I2RS agent to 139 an I2RS client. 141 2. The I2RS protocol SHOULD support a high bandwidth, asynchronous 142 interface, with real-time guarantees on getting data from an 143 I2RS agent by an I2RS client. 145 3. The I2RS protocol will operate on data models which MAY be 146 protocol independent or protocol dependent. 148 4. I2RS Agent MUST record the client identity when a node is 149 created or modified. The I2RS Agent SHOULD to be able to read 150 the client identity of a node and use the client identity's 151 associated priority to resolve conflicts. The secondary 152 identity is useful for traceability and may also be recorded. 154 5. Client identity MUST have only one priority for the client's 155 identifier. A collision on writes is considered an error, but 156 the priority associated with each client identifier is utilized 157 to compare requests from two different clients in order to 158 modify an existing node entry. Only an entry from a client 159 which is higher priority can modify an existing entry (First 160 entry wins). Priority only has meaning at the time of use. 162 6. The Agent identity and the Client identity SHOULD be passed 163 outside of the I2RS protocol in a authentication and 164 authorization protocol (AAA). Client priority may be passed in 165 the AAA protocol. The values of identities are originally set 166 by operators, and not standardized. 168 7. An I2RS Client and I2RS Agent MUST mutually authenticate each 169 other based on pre-established authenticated identities. 171 8. Secondary identity data is read-only meta-data that is recorded 172 by the I2RS agent associated with a data model's node is 173 written, updated or deleted. Just like the primary identity, 174 the secondary identity SHOULD only be recorded when the data 175 node is written or updated or deleted 177 9. I2RS agent MAY have a lower priority I2RS client attempting to 178 modify a higher priority client's entry in a data model. The 179 filtering out of lower priority clients attempting to write or 180 modify a higher priority client's entry in a data model SHOULD 181 be effectively handled and not put an undue strain on the I2RS 182 agent. 184 10. The I2RS protocol MUST support the use of a secure transport. 185 However, certain functions such as notifications MAY use a non- 186 secure transport. Each model or service (notification, logging) 187 must define within the model or service the valid uses of a non- 188 secure transport. 190 3. Ephemeral State Requirements 192 3.1. Persistence 194 Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does 195 not persist across reboots. If state must be restored, it should be 196 done solely by replay actions from the I2RS client via the I2RS 197 agent. 199 While at first glance this may seem equivalent to the writable- 200 running data store in NETCONF, running-config can be copied to a 201 persistent data store, like startup config. I2RS ephemeral state 202 MUST NOT be persisted. 204 3.2. Constraints 206 Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral 207 state for constraint purposes; it SHALL be considered a validation 208 error if it does. 210 Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary 211 operational state (e.g. MPLS LSP-ID or a BGP IN-RIB) as a 212 constraints. 214 Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state 215 for purposes of implementing constraints. The designer of ephemeral 216 state modules are advised that such constraints may impact the speed 217 of processing ephemeral state commits and should avoid them when 218 speed is essential. 220 Ephemeral-REQ-05: Ephemeral state handling and notifications could 221 increase need for CPU processing, data flow rates across a transport, 222 or the rate of publication of data in a subscription or the logging 223 for traceability. The I2RS Agent SHOULD have the ability to 224 constraints for OAM functions operating to limit CPU processing, data 225 rate across a transport, the rate of publication of data in a 226 subscription, and logging rates; and the I2RS Agent SHOULD have the 227 ability to prioritize some of the management data flows between the 228 I2RS Agent and I2RS Client. In order to constrain resources needed, 229 the I2RS Agent MAY also schedule data flows or split data flows unto 230 multiple data flow streams. 232 3.3. Hierarchy 234 Ephemeral-REQ-06: The ability to augment an object with appropriate 235 YANG structures that have the property of being ephemeral. An object 236 defined as any one of the following: 238 o Yang module(and the module's schema tree), 240 o submodule or components of a submodule (e.g. derived types, 241 groupings, data node, RPCs, actions, and notifications), or 243 o a schema node (container, leaf, leaf-list, choice, case, rpc, 244 input, output, notifications, and anyxml). 246 See [I-D.hares-i2rs-protocol-strawman] for examples of yang syntax. 248 4. YANG Features for Ephemeral State for I2RS Protocol version 1 250 Ephemeral-REQ-07: Yang MUST have a way to indicate in a data model 251 that nodes have the following properties: ephemeral, writable/not- 252 writable, and status/configuration. Yang must also have a way to 253 specify on a model or sub-model level whether the data MAY optionally 254 flow across an non-secure transport. 256 5. NETCONF Features for Ephemeral State for I2RS Protocol version 1 258 Ephemeral-REQ-08: The conceptual changes to NETCONF 260 1. protocol version support for I2RS modifications - (e.g. I2RS 261 version 1) 263 2. support for ephemeral model scope indication - which indicates 264 whether a module is an ephemeral-only module or mixed ephemeral 265 config (ephemeral + config), mixed derived state (ephemeral and 266 opstate). 268 3. multiple message support - supports the I2RS "all or nothing" 269 concept ([I-D.ietf-i2rs-architecture] section 7.9) which is the 270 same as NETCONF "roll-back-on-error". 272 4. support for the following transports protocol supported: "TCP", 273 "SSH", "TLS", and non-secure transport (see 274 [I-D.ietf-i2rs-protocol-security-requirements] section 3.2 in 275 requirements SEC-REQ-09 and SEC-REQ-11 for details). NETCONF 276 should be able to expand the number of secure transport protocols 277 supported as I2RS may add additional transport protocols. 279 5. ability to restrict non-secure transport support to specific 280 portions of a data models marked as valid to transfer via 281 insecure protocol. 283 6. ephemeral state overwriting of configuration state MUST be 284 controlled by the following policy knobs (as defined by 285 [I-D.ietf-i2rs-architecture] section 6.3 and 6.3.1): 287 * ephemeral configuration overwrites local configuration (true/ 288 false; normal value: true), and 290 * Update of local configuration value supersedes and overwrites 291 the ephemeral configuration (true/false; normal value: false). 293 7. The ephemeral overwriting to local configuration described in (6) 294 above is considered to be the composite of all ephemeral values 295 by all clients. Some may consider this approach as a single pane 296 of glass for ephemeral state. 298 8. The ephemeral state must support notification of write conflicts 299 using the priority requirements defined in section 7 below in 300 requirements Ephemeral-REQ-10 through Ephemeral-REQ-13). 302 9. Ephemeral data stores SHOULD not require support interactions 303 with writable-running, candidate data store, confirmed commit, 304 and a distinct start-up capability, 306 This list of requirements require the following the following 307 existing features are supported: 309 support for the following encodings: XML or JSON. 311 support for the following transports protocol supported: "TCP", 312 "SSH", "TLS". 314 all of the following NETCONF protocol [RFC6241] specifications: 316 * yang pub-sub push [I-D.ietf-netconf-yang-push], 318 * yang module library [I-D.ietf-netconf-yang-library], 320 * call-home [I-D.ietf-netconf-call-home], and 322 * server model [I-D.ietf-netconf-server-model] with the server 323 module must be augmented to support mutual authentication (see 324 [I-D.ietf-i2rs-protocol-security-requirements] section 3.1 in 325 requirements: SEC-REQ-01 to SEC-REQ-08). 327 6. RESTCONF Features for Ephemeral State for I2RS Protocol version 1 329 Ephemeral-REQ-09: The conceptual changes to RESTCONF are: 331 1. protocol version support for I2RS protocol modification (e.g. 332 I2RS-version 1). 334 2. ephemeral model scope allowed - ephemeral modules, mixed config 335 module (ephemeral and config), mixed derived state (ephemeral and 336 opstate). 338 3. support for both of the following transport protocol suites: 340 * HTTP over TLS (secure HTTP as defined in RESTCONF 341 [I-D.ietf-netconf-restconf] section 2), 343 * HTTP used in a non-secure fashion (See 344 [I-D.ietf-i2rs-protocol-security-requirements], section 3.2, 345 requirements SEC-REQ-09 and SEC-REQ-11 for details), and 347 * RESTCONF SHOULD be able to expand the transports supported as 348 as future I2RS protocol versions may support other transports. 350 4. The ability to restrict insecure transports to specific portions 351 of a data model marked as valid to transfer via an insecure 352 protocol. 354 5. Support for the development of a RESTCONF based yang pub-sub push 355 based on the requirements in [I-D.ietf-i2rs-pub-sub-requirements] 356 and equivalent to the netconf . [I-D.ietf-netconf-yang-push] 358 6. ephemeral state overwriting of configuration state MUST be 359 controlled by the following policy knobs (as defined by 360 [I-D.ietf-i2rs-architecture] section 6.3 and 6.3.1) 362 * Ephemeral configuration overwrites local configuration (true/ 363 false; normal value:true), and 365 * Update of local configuration value supersedes and overwrites 366 the ephemeral configuration (true/false; normal value:false). 368 7. The ephemeral state overwriting a local configuration described 369 above is considered to be the composite of all ephemeral state 370 values by all clients. Some may consider this a single "pane of 371 glass" for the ephemeral values. 373 8. RESTCONF support ephemeral state MUST support notification of 374 write conflicts using the priority requirements (see section 7 375 below, specifically requirements Ephemeral-REQ-10 through 376 Ephemeral-REQ-13). Expansion of existing "edit-collision" 377 features (timestamp and Entity tag) to include I2RS client- 378 priorities is preferred since I2RS client-Agents exchange MAY 379 wish to use the existing edit-collision features in RESTCONF. 381 9. Ephemeral data stores SHOULD not require support for interactions 382 with writeable-running, candidate data stores, confirmed commit, 383 and a distinct start-up capability. 385 This requirement also requires that RESTCONF support all of the 386 following specifications: 388 1. support for the following encodings: XML or JSON. 390 2. all of the following current RESTCONF specifications: 392 1. RESTCONF [I-D.ietf-netconf-restconf], 394 2. the yang-patch features as specified in 395 [I-D.ietf-netconf-yang-patch], 397 3. yang module library [I-D.ietf-netconf-yang-library] as 398 defined in RESTCONF [I-D.ietf-netconf-restconf] section 399 3.3.3), 401 4. call-home [I-D.ietf-netconf-call-home], 403 5. zero-touch [I-D.ietf-netconf-zerotouch], and 405 6. server modules [I-D.ietf-netconf-server-model] (server module 406 must be augmented to support mutual authentication). 408 7. Requirements regarding Supporting Multi-Head Control via Client 409 Priority 411 To support Multi-Headed Control, I2RS requires that there be a 412 decidable means of arbitrating the correct state of data when 413 multiple clients attempt to manipulate the same piece of data. This 414 is done via a priority mechanism with the highest priority winning. 415 This priority is per-client. 417 Ephemeral-REQ-10: The data nodes MAY store I2RS client identity and 418 not the effective priority at the time the data node is stored. Per 419 SEC-REQ-07 in section 3.1 of 420 [I-D.ietf-i2rs-protocol-security-requirements], an identifier must 421 have just one priority. Therefore, the data nodes MAY store I2RS 422 client identity and not the effective priority of the I2RS client at 423 the time the data node is stored. The priority MAY be dynamically 424 changed by AAA, but the exact actions are part of the protocol 425 definition as long as collisions are handled as described in 426 Ephemeral-REQ-10, Ephemeral-REQ-11, and Ephemeral-REQ-12. 428 Ephemeral-REQ-11: When a collision occurs as two clients are trying 429 to write the same data node, this collision is considered an error 430 and priorities were created to give a deterministic result. When 431 there is a collision, a notification MUST BE sent to the original 432 client to give the original client a chance to deal with the issues 433 surrounding the collision. The original client may need to fix their 434 state. 436 Ephemeral-REQ-12: The requirement to support multi-headed control is 437 required for collisions and the priority resolution of collisions. 438 Multi-headed control is not tied to ephemeral state. I2RS is not 439 mandating how AAA supports priority. Mechanisms which prevent 440 collisions of two clients trying the same node of data are the focus. 442 Ephemeral-REQ-13: If two clients have the same priority, the 443 architecture says the first one wins. The I2RS protocol has this 444 requirement to prevent was the oscillation between clients. If one 445 uses the last wins scenario, you may oscillate. That was our 446 opinion, but a design which prevents oscillation is the key point. 448 8. Multiple Message Transactions 450 Ephemeral-REQ-14: Section 7.9 of the [I-D.ietf-i2rs-architecture] 451 states the I2RS architecture does not include multi-message atomicity 452 and roll-back mechanisms. I2RS notes multiple operations in one or 453 more messages handling can handle errors within the set of operations 454 in many ways. No multi-message commands SHOULD cause errors to be 455 inserted into the I2RS ephemeral data-store. 457 9. Pub/Sub Requirements Expanded for Ephemeral State 459 I2RS clients require the ability to monitor changes to ephemeral 460 state. While subscriptions are well defined for receiving 461 notifications, the need to create a notification set for all 462 ephemeral configuration state may be overly burdensome to the user. 464 There is thus a need for a general subscription mechanism that can 465 provide notification of changed state, with sufficient information to 466 permit the client to retrieve the impacted nodes. This should be 467 doable without requiring the notifications to be created as part of 468 every single I2RS module. 470 The publication/subscription requirements for I2RS are in 471 [I-D.ietf-i2rs-pub-sub-requirements], and the following general 472 requirements SHOULD be understood to be expanded to to include 473 ephemeral state: 475 o Pub-Sub-REQ-01: The Subscription Service MUST support 476 subscriptions against ephemeral data in operational data stores, 477 configuration data stores or both. 479 o Pub-Sub-REQ-02: The Subscription Service MUST support filtering so 480 that subscribed updates under a target node might publish only 481 ephemeral data in operational data or configuration data, or 482 publish both ephemeral and operational data. 484 10. IANA Considerations 486 There are no IANA requirements for this document. 488 11. Security Considerations 490 The security requirements for the I2RS protocol are covered in 491 [I-D.ietf-i2rs-protocol-security-requirements] document. The 492 security requirements for the I2RS protocol environment are in 493 [I-D.ietf-i2rs-security-environment-reqs]. 495 12. Acknowledgements 497 This document is an attempt to distill lengthy conversations on the 498 I2RS mailing list for an architecture that was for a long period of 499 time a moving target. Some individuals in particular warrant 500 specific mention for their extensive help in providing the basis for 501 this document: 503 o Alia Atlas 505 o Andy Bierman 507 o Martin Bjorklund 509 o Dean Bogdanavich 511 o Rex Fernando 513 o Joel Halpern 515 o Thomas Nadeau 517 o Juergen Schoenwaelder 519 o Kent Watsen 521 13. References 523 13.1. Normative References: 525 [I-D.ietf-i2rs-architecture] 526 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 527 Nadeau, "An Architecture for the Interface to the Routing 528 System", draft-ietf-i2rs-architecture-15 (work in 529 progress), April 2016. 531 [I-D.ietf-i2rs-protocol-security-requirements] 532 Hares, S., Migault, D., and J. Halpern, "I2RS Security 533 Related Requirements", draft-ietf-i2rs-protocol-security- 534 requirements-06 (work in progress), May 2016. 536 [I-D.ietf-i2rs-pub-sub-requirements] 537 Voit, E., Clemm, A., and A. Prieto, "Requirements for 538 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 539 requirements-09 (work in progress), May 2016. 541 [I-D.ietf-i2rs-security-environment-reqs] 542 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 543 Security Requirements", draft-ietf-i2rs-security- 544 environment-reqs-01 (work in progress), April 2016. 546 [I-D.ietf-i2rs-traceability] 547 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 548 the Routing System (I2RS) Traceability: Framework and 549 Information Model", draft-ietf-i2rs-traceability-11 (work 550 in progress), May 2016. 552 [I-D.ietf-netconf-call-home] 553 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 554 draft-ietf-netconf-call-home-17 (work in progress), 555 December 2015. 557 [I-D.ietf-netconf-restconf] 558 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 559 Protocol", draft-ietf-netconf-restconf-13 (work in 560 progress), April 2016. 562 [I-D.ietf-netconf-server-model] 563 Watsen, K. and J. Schoenwaelder, "NETCONF Server and 564 RESTCONF Server Configuration Models", draft-ietf-netconf- 565 server-model-09 (work in progress), March 2016. 567 [I-D.ietf-netconf-yang-library] 568 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 569 Library", draft-ietf-netconf-yang-library-06 (work in 570 progress), April 2016. 572 [I-D.ietf-netconf-yang-patch] 573 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch 574 Media Type", draft-ietf-netconf-yang-patch-08 (work in 575 progress), March 2016. 577 [I-D.ietf-netconf-yang-push] 578 Clemm, A., Prieto, A., Voit, E., Tripathy, A., and E. 579 Einar, "Subscribing to YANG datastore push updates", 580 draft-ietf-netconf-yang-push-02 (work in progress), March 581 2016. 583 [I-D.ietf-netconf-zerotouch] 584 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning 585 for NETCONF or RESTCONF based Management", draft-ietf- 586 netconf-zerotouch-08 (work in progress), April 2016. 588 [I-D.ietf-netmod-yang-metadata] 589 Lhotka, L., "Defining and Using Metadata with YANG", 590 draft-ietf-netmod-yang-metadata-07 (work in progress), 591 March 2016. 593 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 594 and A. Bierman, Ed., "Network Configuration Protocol 595 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 596 . 598 13.2. Informative References 600 [I-D.hares-i2rs-protocol-strawman] 601 Hares, S., Bierman, A., and a. amit.dass@ericsson.com, 602 "I2RS protocol strawman", draft-hares-i2rs-protocol- 603 strawman-02 (work in progress), May 2016. 605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 606 Requirement Levels", BCP 14, RFC 2119, 607 DOI 10.17487/RFC2119, March 1997, 608 . 610 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 611 the Network Configuration Protocol (NETCONF)", RFC 6020, 612 DOI 10.17487/RFC6020, October 2010, 613 . 615 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 616 Protocol (NETCONF) Access Control Model", RFC 6536, 617 DOI 10.17487/RFC6536, March 2012, 618 . 620 Authors' Addresses 622 Jeff Haas 623 Juniper 625 Email: jhaas@juniper.net 627 Susan Hares 628 Huawei 629 Saline 630 US 632 Email: shares@ndzh.com