--- 1/draft-ietf-netmod-revised-datastores-06.txt 2017-11-29 08:15:19.756352115 -0800 +++ 2/draft-ietf-netmod-revised-datastores-07.txt 2017-11-29 08:15:19.824353666 -0800 @@ -1,24 +1,24 @@ Network Working Group M. Bjorklund Internet-Draft Tail-f Systems Updates: 7950 (if approved) J. Schoenwaelder Intended status: Standards Track Jacobs University -Expires: May 3, 2018 P. Shafer +Expires: June 2, 2018 P. Shafer K. Watsen Juniper Networks R. Wilton Cisco Systems - October 30, 2017 + November 29, 2017 Network Management Datastore Architecture - draft-ietf-netmod-revised-datastores-06 + draft-ietf-netmod-revised-datastores-07 Abstract Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as NETCONF and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 3, 2018. + This Internet-Draft will expire on June 2, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -68,35 +68,36 @@ 5.1.3. The Running Configuration Datastore () . . . 11 5.1.4. The Intended Configuration Datastore () . . 12 5.2. Dynamic Configuration Datastores . . . . . . . . . . . . 13 5.3. The Operational State Datastore () . . . . . 13 5.3.1. Remnant Configuration . . . . . . . . . . . . . . . . 14 5.3.2. Missing Resources . . . . . . . . . . . . . . . . . . 14 5.3.3. System-controlled Resources . . . . . . . . . . . . . 15 5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15 6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 16 6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 16 - 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17 + 6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 17 + 7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 23 - 8.2. Updates to the YANG Module Names Registry . . . . . . . . 23 + 8.2. Updates to the YANG Module Names Registry . . . . . . . . 24 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 - 11.2. Informative References . . . . . . . . . . . . . . . . . 25 - Appendix A. Guidelines for Defining Datastores . . . . . . . . . 26 + 11.2. Informative References . . . . . . . . . . . . . . . . . 26 + Appendix A. Guidelines for Defining Datastores . . . . . . . . . 27 A.1. Define which YANG modules can be used in the datastore . 27 A.2. Define which subset of YANG-modeled data applies . . . . 27 A.3. Define how data is actualized . . . . . . . . . . . . . . 27 - A.4. Define which protocols can be used . . . . . . . . . . . 27 - A.5. Define YANG identities for the datastore . . . . . . . . 27 + A.4. Define which protocols can be used . . . . . . . . . . . 28 + A.5. Define YANG identities for the datastore . . . . . . . . 28 Appendix B. Ephemeral Dynamic Configuration Datastore Example . 28 Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 29 C.1. System Example . . . . . . . . . . . . . . . . . . . . . 29 C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 32 C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 34 C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 34 C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 35 C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 36 C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 36 C.3.2. System-provided Interface . . . . . . . . . . . . . . 37 @@ -767,20 +768,32 @@ o If the XPath expression is defined in a substatement to an "output" statement in an "rpc" or "action" statement, the accessible tree is the RPC or action operation instance and all operational state in the server. The root node has top-level data nodes in all modules as children. Additionally, for an RPC, the root node also has the node representing the RPC operation being defined as a child. The node representing the operation being defined has the operation's output parameters as children. +6.2. Invocation of Actions and RPCs + + This section updates section 7.15 of RFC 7950. + + Actions are always invoked in the context of the operational state + datastore. The node for which the action is invoked MUST exist in + the operational state datastore. + + Note that this document does not constrain the result of invoking an + RPC or action in any way. For example, an RPC might be defined to + modify the contents of some datastore. + 7. YANG Modules file "ietf-datastores@2017-08-17.yang" module ietf-datastores { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-datastores"; prefix ds; organization @@ -1469,21 +1480,21 @@ container bgp { leaf local-as { type uint32; } leaf peer-as { type uint32; } list peer { key name; leaf name { - type ipaddress; + type inet:ip-address; } leaf local-as { type uint32; description ".... Defaults to ../local-as"; } leaf peer-as { type uint32; description "... Defaults to ../peer-as";