idnits 2.17.1 draft-bjorklund-netmod-openconfig-reply-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2015) is 3188 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bjorklund 3 Internet-Draft Tail-f Systems 4 Intended status: Informational A. Bierman 5 Expires: January 7, 2016 YumaWorks 6 J. Schoenwaelder 7 Jacobs University 8 K. Watsen 9 Juniper Networks 10 July 6, 2015 12 Comments on Data Organization and Operational State 13 draft-bjorklund-netmod-openconfig-reply-00 15 Abstract 17 This document is a reply to OpenConfig's proposed solutions to some 18 common data modeling problems. 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 January 7, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Supporting "asynchronous" implementations. . . . . . . . . . 2 68 2.1. Alternative Solution . . . . . . . . . . . . . . . . . . 3 69 3. Need a way to relate config to state. . . . . . . . . . . . . 3 70 3.1. Alternative . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Top-level node . . . . . . . . . . . . . . . . . . . . . . . 4 72 4.1. Alternative . . . . . . . . . . . . . . . . . . . . . . . 4 73 5. Informative References . . . . . . . . . . . . . . . . . . . 4 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 76 1. Introduction 78 This document is a reply to OpenConfig's proposed solutions to some 79 common data model-ling problems, as presented in 80 [I-D.openconfig-netmod-opstate] and 81 [I-D.openconfig-netmod-model-structure]. 83 2. Supporting "asynchronous" implementations. 85 In [I-D.openconfig-netmod-opstate], the authors propose that all 86 configuration nodes are duplicated in a separate config false branch 87 of the data tree, in order to support "asynchronous" implementations. 88 The config true part of the tree is called "intended configuration", 89 and is always modeled under a NP container "config", and the 90 duplicate part is called "actual configuration", and is always model- 91 led under a NP container "state". 93 Cons: 95 o Data model duplication. This reduces the readability of the 96 models, uses additional memory in implementations, and adds to the 97 complexity of the overall solution. 98 o Fragile solution, since it relies on a convention; if a 99 module doesn't follow this convention, that module cannot 100 be used in a such a system. 101 o Adding semantics to node names instead of using YANG 102 statements. 103 o Relies on groupings and therefore the YANG constraints 104 will be applied to the config=false copy, even if the 105 operational state does not have the same restrictions as 106 the config. 107 o Mandatory for all platforms even if asynch does not apply. 108 o Some leafrefs will be broken - if a leafref has the 109 "config" node in its path, then the "state" version of 110 the leafref still refers to the "config" node. 112 2.1. Alternative Solution 114 We propose that the actual config is handled as a separate conceptual 115 datastore. In NETCONF, this can be done by using get-config with a 116 new datastore name. Other protocols would do something similar. 118 Pros: 120 o This works without rewriting any modules already 122 published. It works with vendor models and models from other SDOs 123 that do not follow these conventions. 124 o Doesn't cost anything for platforms where asynch does 125 not apply. 127 Cons: 129 o Needs a datastore, a concept that not all protocols support. 131 However, the protocol does not have to expose the datastores in the 132 same way as NETCONF in order to support this concept. For 133 example, RESTCONF does not have datastores in the way that NETCONF 134 does, and it can easily be updated to support the "actual" config 135 (and "ephemeral"). 137 3. Need a way to relate config to state. 139 In [I-D.openconfig-netmod-opstate], the authors propose that all data 140 models always add two special NP containers "config" and "state" 141 which contains all leafs, in order to have a simple and deterministic 142 way to related config to state. 144 Cons: 146 o Too simplistic. Doesn't solve the problem that the 148 state may contain different instances than config. 149 Configuration data and operational instances are really 150 separate entities, and should be modeled as such. 151 o Adds noise to the data model. 152 o Fragile solution, since it relies on a convention; if a 153 module doesn't follow this convention, that module cannot 154 be used in a such a system. 155 o Adds semantics to node names instead of using YANG statements. 156 o If the data model has an address list that has "city, 157 state, zipcode" the convention doesn't work. 159 3.1. Alternative 161 The solution in [RFC7223]. 163 It should be noted that in both the open config proposal and the 164 scheme from [RFC7223], there is no formal way to know the 165 relationship between the configuration and its related operational 166 state. It might be worthwhile to try to define YANG statements to 167 solve this problem instead. 169 4. Top-level node 171 In [I-D.openconfig-netmod-model-structure], the authors propose that 172 all data models intended for devices are rooted under a top-level 173 node called "device". 175 Cons: 177 o Doesn't solve any problem. It just adds 7 characters to 179 all paths. Whatever problem there is today with "/FOO" 180 will now be a problem with "/device/FOO". 181 o All existing models need to be rewritten, including vendor models. 183 4.1. Alternative 185 Use "/" as the top level. 187 5. Informative References 189 [I-D.openconfig-netmod-model-structure] 190 Shaikh, A., Shakir, R., D'Souza, K., and L. Fang, 191 "Operational Structure and Organization of YANG Models", 192 draft-openconfig-netmod-model-structure (work in 193 progress), March 2015. 195 [I-D.openconfig-netmod-opstate] 196 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 197 of Operational State Data in YANG", draft-openconfig- 198 netmod-opstate (work in progress), March 2015. 200 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 201 Management", RFC 7223, May 2014. 203 Authors' Addresses 205 Martin Bjorklund 206 Tail-f Systems 208 Email: mbj@tail-f.com 210 Andy Bierman 211 YumaWorks 213 Email: andy@yumaworks.com 215 Juergen Schoenwaelder 216 Jacobs University 218 Email: j.schoenwaelder@jacobs-university.de 220 Kent Watsen 221 Juniper Networks 223 Email: kwatsen@juniper.net