idnits 2.17.1 draft-openconfig-netmod-opstate-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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 == Line 291 has weird spacing: '...ty-time yan...' == Line 317 has weird spacing: '...terface oci...' -- The document date (March 9, 2015) is 3336 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'YANG-IF' is mentioned on line 251, but not defined ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-16 == Outdated reference: A later version (-02) exists of draft-shaikh-idr-bgp-model-01 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Shakir 3 Internet-Draft BT 4 Intended status: Informational A. Shaikh 5 Expires: September 10, 2015 M. Hines 6 Google 7 March 9, 2015 9 Consistent Modeling of Operational State Data in YANG 10 draft-openconfig-netmod-opstate-00 12 Abstract 14 This document proposes an approach for modeling configuration and 15 operational state data in YANG that is geared toward network 16 management systems that require capabilities beyond those typically 17 envisioned in a NETCONF-based management system. The document 18 presents the requirements of such systems and proposes a modeling 19 approach to meet these requirements, along with implications and 20 design patterns for modeling operational state in YANG. 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 10, 2015. 39 Copyright Notice 41 Copyright (c) 2015 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 1. Introduction 56 Retrieving the operational state of a network element (NE) is a 57 critical process for a network operator, both because it determines 58 how the network is currently running (for example, how many errors 59 are occurring on a certain link, what is the load of that link); but 60 also because it determines whether the intended configuration applied 61 by a network management system is currently operational. Whilst 62 changing of the configuration of NE may be a process which occurs 63 relatively infrequently, the accessing of the state of the network is 64 significantly more often - with knowledge of the real-time state of 65 the network by external analysis and diagnostic systems being desired 66 (implying reading of this data on the order of millisecond 67 timescales). 69 It is desirable to model configuration and operational state within a 70 single schema. This allows a network operator or management system 71 to retrieve information as to the intended state of the network 72 system (the configuration), and easily relate to this to the actual 73 running state. There are numerous reasons that the intended state 74 may not be reflected by the running config: 76 o Protocol negotiations may be required for multiple NEs to agree on 77 a certain running value - for example, the HOLDTIME of a BGP 78 session is chosen by taking the minimum value of the locally 79 configured and advertised value received from the remote speaker. 80 The operational value of the HOLDTIME may therefore be lower than 81 the configured value on the local system. 83 o Where the application of a change is asynchronous - due to system 84 operations, or a pre-requisite for another event to occur before 85 the configuration value is applied (e.g., a protocol session 86 restart) - then the intended configuration value may not determine 87 whether the configuration has been committed to the running 88 configuration; or whether the pre-requisite event has occurred. 90 Based on such differences between intended and running state, the 91 operation of checking one state and then subsequently applying a 92 change is very common. For example, checking the current IGP metric 93 of a certain link, and if it is not reflective of the desired value, 94 subsequently applying a change. Rather than viewing configuration 95 and operational state separately, having both types of values in a 96 common location within the same data schema is advantageous. In this 97 way, no complex mapping between the path where the value is read, and 98 the path by which it is configured is required. 100 The majority of existing designs of the layout and presentation of a 101 YANG [RFC6020] model considers only the semantics of the NETCONF 102 protocol - however, it is advantageous that any data model (expressed 103 in YANG) should be suitable for use with multiple protocols. Such 104 protocols may be alternatives to NETCONF - e.g., RESTCONF - but also 105 may be specifically engineered for accessing particular operational 106 data (e.g., streamed data from a network element, rather than 'SNMP- 107 like' polled mechanisms). 109 Based on the inherent link between the configuration and state data 110 for a NE, and the importance of state for a network operator, YANG's 111 focus solely on configuration data is suboptimal[RFC6244]. We 112 therefore consider that there is a requirement to consider (and 113 define common approaches for) the definition of state and operational 114 data within a YANG model. Such considerations should be cognisant of 115 the protocols used to interact with the data schema. 117 2. Operational requirements 119 Our proposal is motivated by a number of operational requirements as 120 described below. 122 2.1. Intended configuration as part of operational state 124 The definition of operational state in [RFC6244] includes read-only 125 transient data that is the result of system operation or protocol 126 interactions, and data that is typically thought of as counters or 127 statistics. In many operational use cases it is also important to 128 distinguish between the intended value of a configuration variable 129 and its actual configured state, analogous to candidate and running 130 configuration, respectively, in NETCONF datastores. In non- 131 transactional or asynchronous environments, for example, these may be 132 different and it is important to know when they are different or when 133 they have converged (see requirement #2). For this reason, we 134 consider the intended configuration as an additional important 135 element of the operational state. This is not considered in 136 [RFC6244]. 138 2.2. Support for both transactional, synchronous management systems as 139 well as distributed, asynchronous management systems 141 In a synchronous system, configuration changes are transactional and 142 committed as an atomic unit. This implies that the management system 143 knows the success or failure of the configuration change based on the 144 return value, and hence knows that the intended configuration matches 145 what is on the system. In particular, the value of any configuration 146 variable should always reflect the (intended) configured value. 147 Synchronous operation is generally associated with a NETCONF-based 148 system that provides transactional semantics for all changes. 150 In an asynchronous system, configuration changes to the system may 151 not be reflected immediately, even though the change operation 152 returns success. Rather, the change is verified by observing the 153 state of the system, for example based on notifications, or 154 continuously streamed values of the state. In this case, the value 155 of a configuration variable may not reflect the intended configured 156 value at a given point in time. 158 The asynchronous use case is important because synchronous operation 159 may not always be possible. For example, in a large scale 160 environment, the management system may not need to wait for all 161 changes to complete if it is acceptable to proceed while some 162 configuration values are being updated. In addition, not all devices 163 may support transactional changes, making asynchronous operation a 164 requirement. Moreover, using observed state to infer the configured 165 value allows the management system to learn the time taken to 166 complete various configuration changes. 168 2.3. Separation of configuration and operational state data; ability to 169 retrieve them independently 171 These requirements are also mentioned in [RFC3535]: 173 o It is necessary to make a clear distinction between configuration 174 data, data that describes operational state and statistics. 176 o It is required to be able to fetch separately configuration data, 177 operational state data, and statistics from devices, and to be 178 able to compare these between devices. 180 2.4. Ability to retrieve operational state corresponding only to 181 derived values, statistics, etc. 183 When the management system operates in synchronous mode, it should be 184 able to retrieve only the operational state corresponding to the 185 system determined values, such as negotiated values, protocol 186 determined values, or statistics and counters. Since in synchronous 187 mode the intended and actual configuration values are identical, 188 sending the intended configuration state is redundant. 190 2.5. Consistent schema locations for configuration and corresponding 191 operational state data 193 This requirement implies that a common convention is used throughout 194 the schema to locate configuration and state data so that the 195 management system can infer how to access one or the other without 196 needing significant external context. When considering intended 197 configuration as part of operational state (as discussed in 198 Section 2.1), it is similarly required that the intended value vs. 199 actual value for a particular configuration variable should be 200 possible to locate with minimal, if any, mapping information. 202 This requirement becomes more evident when considering the 203 composition of individual data models into a higher-level model for a 204 complete device (e.g., /device[name=devXY]/protocols/routing/...) or 205 even higher layer models maintained by network operators (e.g., /ope 206 ratorX/global/continent[name=eur]/pop[name=paris]/device[name=devXY] 207 /...). If each model has it's own way to separate configuration and 208 state data, then this information must be known at potentially every 209 subtree of the composed model. 211 3. Implications on modeling operational state 213 The requirements in Section 2 give rise to a number of new 214 considerations for modeling operational state. Some of the key 215 implications are summarized below. 217 3.1. Inclusion of intended configuration as part of operational state 219 This implies that a copy of the configurable (i.e., writable) values 220 should be included as read-only variables in containers for 221 operational state, in addition to the variables that are 222 traditionally thought of as state variables (counters, negotiated 223 values, etc.). 225 3.2. Corresponding leaves for configuration and state 227 Any configuration leaf should have a corresponding state leaf. The 228 opposite is clearly not true -- some parts of the model may only have 229 derived state variables, for example the contents of a routing table 230 that is populated by a dynamic routing protocols like BGP or IS-IS. 232 3.3. Retrieval of only the derived, or NE-generated part of the 233 operational state 235 YANG and NETCONF do not currently differentiate between state that is 236 derived by the NE, state representing statistics, and state 237 representing intended configuration -- all state is simply marked as 238 'config false' or read-only. To retrieve only the state that is not 239 part of intended configuration, we require a new way to tag such 240 data. This is proposed in this document as a YANG extension. 241 Alternatively, as described in [RFC6244], a new NETCONF datastore for 242 operational state that is just for NE- generated state could also be 243 used to allow (or similar) operations to specify just that part 244 of the state. 246 3.4. Consistency and predictability in the paths where corresponding 247 state and configuration data may be retrieved 249 To avoid arbitrary placement of state and configuration data 250 containers, the most consistent options would be at the root of the 251 model (as done in [YANG-IF]) or at the leaves, i.e., at the start or 252 end of the paths. When operators compose models into a higher level 253 model, the root of the model is no longer well-defined, and hence 254 neither is the start of the path. For these reasons, we propose 255 placing configuration and state separation at leaves of the model. 257 3.5. Reuse of existing NETCONF conventions where applicable 259 Though not a specific requirement, models for operational state 260 should take advantage of existing protocol mechanisms where possible, 261 e.g., to retrieve configuration and state data. 263 4. Proposed operational state structure 265 Below we show an example model structure that meets the requirements 266 described above for all four types of data we are considering: 268 o configuration (writable) data 270 o operational state data on the NE that is derived, negotiated, set 271 by a protocol, etc. 273 o operational state data for counters or statistics 275 o operational state data representing intended configuration 277 4.1. Example model structure 279 The example below shows a partial model (in ascii tree format) for 280 managing Ethernet aggregate interfaces (leveraging data definitions 281 from [RFC7223]): 283 +--rw interfaces 284 +--rw interface* [name] 285 +--rw name -> ../config/name 286 +--rw config 287 | ... 288 +--ro state 289 | | ... 290 | +--ro counters 291 | +--ro discontinuity-time yang:date-and-time 292 | +--ro in-octets? yang:counter64 293 | +--ro in-unicast-pkts? yang:counter64 294 | +--ro in-broadcast-pkts? yang:counter64 295 | +--ro in-multicast-pkts? yang:counter64 296 | +--ro in-discards? yang:counter64 297 | +--ro in-errors? yang:counter64 298 | +--ro in-unknown-protos? yang:counter64 299 | +--ro out-octets? yang:counter64 300 | +--ro out-unicast-pkts? yang:counter64 301 | +--ro out-broadcast-pkts? yang:counter64 302 | +--ro out-multicast-pkts? yang:counter64 303 | +--ro out-discards? yang:counter64 304 | +--ro out-errors? yang:counter64 305 +--rw aggregation! 306 +--rw config 307 | +--rw lag-type? aggregation-type 308 | +--rw min-links? uint16 309 +--ro state 310 | +--ro lag-type? aggregation-type 311 | +--ro min-links? uint16 312 | +--ro members* ocif:interface-ref 313 +--rw lacp! 314 +--rw config 315 | +--rw interval? lacp-period-type 316 +--rw members* [interface] 317 | +--rw interface ocif:interface-ref 318 | +--ro state 319 | +--ro activity? lacp-activity-type 320 | +--ro timeout? lacp-timeout-type 321 | +--ro synchronization? lacp-synch-type 322 | +--ro aggregatable? boolean 323 | +--ro collecting? boolean 324 | +--ro distributing? boolean 325 +--ro state 326 +--ro interval? lacp-period-type 328 In this model, the path to the configurable (rw) items at the 329 aggregate interface level is: 331 /interfaces/interface[name=ifName]/aggregation/config/... 333 The corresponding operational state is located at: 335 /interfaces/interface[name=ifName]/aggregation/state/... 337 This container holds a read-only copy of the intended configuration 338 variables (lag-type and min-links), as well as a generated list of 339 member interfaces (the members leaf-list) for the aggregate that is 340 active when the lag-type indicates a statically configured aggregate. 341 Note that although the paths to config and state containers are 342 symmetric, the state container contains additional derived variables. 344 The model has an additional hierarchy level for aggregate interfaces 345 that are maintained using LACP. For these, the configuration path 346 is: 348 /interfaces/interface[name=ifName]/aggregation/lacp/config/... 350 with the corresponding state container (in this case with only the 351 state corresponding to the intended configuration) at: 353 /interfaces/interface[name=ifName]/aggregation/lacp/state/... 355 There is an additional list of members for LACP-managed aggregates 356 with only a state container: 358 /interfaces/interface[name=ifName]/aggregation/lacp/ 359 members[name=ifName]/state/... 361 Note that it is not required that both a state and a config container 362 be present at every leaf. It may be convenient to include an empty 363 config container to make it more explicit to the management system 364 that there are no configuration variables at this location in the 365 data tree. 367 Finally, we can see that the generic interface object also has config 368 and state containers (these are abbreviated for clarity). The state 369 container has a subcontainer for operational state corresponding to 370 counters and statistics that are valid for any interface type: 372 /interfaces/interface[name=ifName]/state/counters/... 374 5. Impact on model authoring 376 One drawback of structuring operational and configuration data in 377 this way is the added complexity in authoring the models, relative to 378 the way some models are currently built with state and config split 379 at the root of the individual model (e.g., in [RFC7223], [RFC7317], 380 and [IETF-RTG]). Moving the config and state containers to each leaf 381 adds a one-time modeling effort, which is somewhat dependent on the 382 model structure itself (how many layers of container hierarchy, 383 number of lists, etc.) However, we feel this effort is justified by 384 the resulting simplicity with which management systems can access and 385 correlate state and configuration data. 387 5.1. Modeling design patterns 389 We propose some specific YANG modeling design patterns that may be 390 useful for building models following these conventions. 392 5.1.1. Basic structure 394 Since leaves that are created under the 'config' container are 395 duplicated under the 'state' container, it is recommended that the 396 following conventions are used to ensure that the schema remain as 397 simple as possible: 399 o A grouping for the 'config' data items is created - with a 400 specific naming convention to indicate that such variables are 401 configurable, such as a suffix like '-config' or '_config'. For 402 example, the OpenConfig BGP model [OC-BGP] adopts the convention 403 of appending "_config" to the name of the container. 405 o A grouping for the 'state' data items is created, with a similar 406 naming convention as above, i.e., with a suffix such as '-state' 407 or '_state'. The BGP model uses "_state". 409 o A structure grouping is created that instantiates both the 410 'config' and 'state' containers. The 'config' container should 411 include the "-config" grouping, whilst the state container has 412 both the "-config" and "-state" groupings, along with the 'config 413 false' statement. 415 A simple example in YANG is shown in Appendix B. 417 5.1.2. Handling lists 419 In YANG 1.0, lists have requirements that complicate the creation of 420 the parallel configuration and state data structures. First, keys 421 must be children of the list; they cannot be further down the data 422 hierarchy within a subsequent container. For example, the 423 'interface' list cannot be keyed by /interfaces/interface/config/ 424 name. Second YANG requires that the list key is part of the 425 configuration or state data in each list member. 427 We consider two possible approaches for lists: 429 1. list keys appear only at the top level of the list, i.e., not 430 duplicated under the 'config' or 'state' containers within the 431 list 433 2. the data represented by the list key appears in the config and 434 state containers, and a key with type leafref is used in the top 435 level of the list pointing to the corresponding data node in the 436 config (or state) container. 438 Option 1 has the advantage of not duplicating data, but treats the 439 data item (or items) that are keys as special cases, i.e., not 440 included in the config or state containers. Option 2 is appealing in 441 that configurable data always appears in the config container, but 442 requires an arguably unnecessary key pointing to the data from the 443 top level of the list. 445 Appendix C shows a simple example of both options. 447 5.1.3. Selective use of state data from common groupings 449 In a number of cases, it is desirable that the same grouping be used 450 within different places in a model - but state information is only 451 relevant in one of these paths. For example, considering BGP, peer 452 configuration is relevant to both a "neighbor" (i.e., an individual 453 BGP peer), and also to a peer-group (a set of peers). Counters 454 relating to the number of received prefixes, or queued messages, are 455 relevant only within the 'state' container of the peer (rather than 456 the peer-group). In this case, use of the 'augment' statement to add 457 specific leaves to only one area of the tree is recommended, since it 458 allows a common container to be utilized otherwise. 460 5.1.4. Non-corresponding configuration and state data 462 There are some instances where only an operational state container is 463 relevant without a corresponding configuration data container. For 464 example, the list of currently active member interfaces in a LACP- 465 managed LAG is typically reported by the system as operational state 466 that is governed by the LACP protocol. Such data is not directly 467 configured. Similarly, counters and statistics do not have 468 corresponding configuration. In these cases, we can either omit the 469 config container from such leaves, or provide an empty container as 470 described earlier. With both options, the management system is able 471 to infer that such data is not configurable. 473 6. YANG language considerations 475 In adopting the approach described in this document for modeling 476 operational state data in YANG, we encounter several language 477 limitations that are described below. We disucss some initial 478 thoughts on possible changes to the language to more easily enable 479 the proposed model for operational state modeling. 481 6.1. Distinguishing derived operational state data and intended 482 configuration 484 As mentioned in Section 2, we require a way to separately query 485 operational state that is not part of intended configuration (e.g., 486 protocol-determined data, counters, etc.). YANG and NETCONF do not 487 distinguish types of operational state data, however. To overcome 488 this, we currently use a YANG language extension to mark such data as 489 'operational: true'. Ideally, this could be generalized beyond the 490 current 'config: true / false' to something like "operational: 491 false", "operational: intent", and "operational:true". 493 6.2. YANG lists as maps 495 YANG has two list constructs, the 'leaf-list' which is similar to a 496 list of scalars in other programming languages, and the 'list' which 497 allows a keyed list of complex structures, where the key is also part 498 of the data values. As described in Section [impact], the current 499 requirements on YANG list keys require either duplication of data, or 500 treating some data (i.e., those that comprise list keys) as a special 501 case. One solution is to generalize lists to be more like map data 502 structures, where each list member has a key that is not required to 503 part of the configuration or state data. This allows list keys to be 504 arbitrarily defined by the user if desired, or based on values of 505 data nodes. In the latter case, the specification of which data 506 nodes are used in constructing the list key could be indicated in the 507 meta-data associated with the key. 509 6.3. Configuration and state data hierarchy 511 YANG does not allow read-write configuration data to be child nodes 512 of read-only operational state data. This requires the definition of 513 separate state and config containers as described above. However, it 514 may be desirable to simplify the schema by 'flattening', e.g., having 515 the operational state as the root of the data tree, with only config 516 containers needed to specify the variables that are writable (in 517 general, the configuration data is much smaller than operational 518 state data). Naming the containers explicitly according the config / 519 state convention makes the intent of the data clear, and should allow 520 relaxing of the current YANG restrictions. That is, a read-write 521 config container makes explicit the nature of the enclosed data even 522 if the parent data nodes are read-only. This of course requires that 523 all data in a config container are in fact configurable -- this is 524 one of the motivations of pushing such containers as far down in the 525 schema hierarchy as possible. 527 7. Security Considerations 529 This document addresses the structure of configuration and 530 operational state data, both of which should be considered sensitive 531 from a security standpoint. Any data models that follows the 532 proposed structuring must be carefully carefully evaluated to 533 determine its security risks. In general, access to both 534 configuration (write) and operational state (read) data must be 535 carefully controlled through appropriate access control and 536 authorization mechanisms. 538 8. References 540 8.1. Normative references 542 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 543 Network Configuration Protocol (NETCONF)", RFC 6020, 544 October 2010. 546 [RFC6244] Shafer, P., "An Architecture for Network Management Using 547 NETCONF and YANG", RFC 6244, June 2011. 549 [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network 550 Management Workshop", RFC 3535, May 2003. 552 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 553 Management", RFC 7223, May 2014. 555 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 556 System Management", RFC 7317, August 2014. 558 8.2. Informative references 560 [IETF-RTG] 561 Lhotka, L., "A YANG Data Model for Routing Management", 562 draft-ietf-netmod-routing-cfg-16 (work in progress), 563 October 2014. 565 [OC-BGP] Shaikh, A., D'Souza, K., Bansal, D., and R. Shakir, "BGP 566 Configuration Model for Service Provider Networks", draft- 567 shaikh-idr-bgp-model-01 (work in progress), March 2015. 569 Appendix A. Acknowledgements 571 The authors are grateful for valuable input to this document from: 572 Martin Bjorklund, Paul Borman, Chris Chase, Feihong Chen, Josh 573 George, Carl Moberg, Jason Sterne, and Jim Uttaro. 575 Appendix B. Example YANG base structure 577 Below we show an example of the basic YANG building block for 578 organizing configuration and operational state data as described in 579 Section 4 581 grouping example-config { 582 description "configuration data for example container"; 584 leaf conf-1 { 585 type empty; 586 } 588 leaf conf-2 { 589 type string; 590 } 591 } 593 grouping example-state { 594 description 595 "operational state data (derived, counters, etc.) for example 596 container"; 598 leaf state-1 { 599 type boolean; 600 } 602 leaf state-2 { 603 type string; 604 } 606 container counters { 607 description 608 "operational state counters for example container"; 610 leaf counter-1 { 611 type uint32; 612 } 614 leaf counter-2 { 615 type uint64; 616 } 618 } 619 } 621 grouping example-structure { 622 description 623 "top level grouping for the example container -- this is used 624 to put the config and state subtrees in the appropriate 625 location"; 627 container example { 628 description 629 "top-level container for the example data"; 631 container config { 633 uses example-config; 635 } 637 container state { 639 config false; 640 uses example-config; 641 uses example-state; 642 } 643 } 644 } 646 uses example-structure; 648 The corresponding YANG data tree is: 650 +--rw example 651 +--rw config 652 | +--rw conf-1? empty 653 | +--rw conf-2? string 654 +--ro state 655 +--ro conf-1? empty 656 +--ro conf-2? string 657 +--ro state-1? boolean 658 +--ro state-2? string 659 +--ro counters 660 +--ro counter-1? uint32 661 +--ro counter-2? uint64 663 Appendix C. Example YANG list structure 665 As described in Section 5.1.2, there are two options we consider for 666 building lists according to the proposed structure. Both are shown 667 in the example YANG snippet below. The groupings defined above in 668 Appendix B are reused here. 670 grouping example-no-conf2-config { 671 description 672 "configuration data for example container but without the conf-2 673 data leaf which is used as a list key"; 675 leaf conf-1 { 676 type empty; 677 } 679 } 681 grouping example-structure { 682 description 683 "top level grouping for the example container -- this is used 684 to put the config and state subtrees in the appropriate 685 location"; 687 list example { 689 key conf-2; 690 description 691 "top-level list for the example data"; 693 leaf conf-2 { 694 type leafref { 695 path "../config/conf-2"; 696 } 697 } 699 container config { 701 uses example-config; 703 } 705 container state { 707 config false; 708 uses example-config; 709 uses example-state; 710 } 712 } 714 list example2 { 716 key conf-2; 717 description 718 "top-level list for the example data"; 720 leaf conf-2 { 721 type string; 722 } 724 container config { 726 uses example-no-conf2-config; 728 } 730 container state { 732 config false; 733 uses example-no-conf2-config; 734 uses example-state; 735 } 736 } 737 } 739 uses example-structure; 741 The corresponding YANG data tree is shown below for both styles of 742 lists. 744 +--rw example* [conf-2] 745 | +--rw conf-2 -> ../config/conf-2 746 | +--rw config 747 | | +--rw conf-1? empty 748 | | +--rw conf-2? string 749 | +--ro state 750 | +--ro conf-1? empty 751 | +--ro conf-2? string 752 | +--ro state-1? boolean 753 | +--ro state-2? string 754 | +--ro counters 755 | +--ro counter-1? uint32 756 | +--ro counter-2? uint64 757 +--rw example2* [conf-2] 758 +--rw conf-2 string 759 +--rw config 760 | +--rw conf-1? empty 761 +--ro state 762 +--ro conf-1? empty 763 +--ro state-1? boolean 764 +--ro state-2? string 765 +--ro counters 766 +--ro counter-1? uint32 767 +--ro counter-2? uint64 769 Authors' Addresses 771 Rob Shakir 772 BT 773 pp. C3L, BT Centre 774 81, Newgate Street 775 London EC1A 7AJ 776 UK 778 Email: rob.shakir@bt.com 779 URI: http://www.bt.com/ 781 Anees Shaikh 782 Google 783 1600 Amphitheatre Pkwy 784 Mountain View, CA 94043 785 US 787 Email: aashaikh@google.com 788 Marcus Hines 789 Google 790 1600 Amphitheatre Pkwy 791 Mountain View, CA 94043 792 US 794 Email: hines@google.com