idnits 2.17.1 draft-nmdsdt-netmod-revised-datastores-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2016) is 2737 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) == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-17 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bjorklund, Ed. 3 Internet-Draft Tail-f Systems 4 Intended status: Standards Track J. Schoenwaelder 5 Expires: April 30, 2017 Jacobs University 6 P. Shafer 7 K. Watsen 8 Juniper 9 R. Wilton 10 Cisco 11 October 27, 2016 13 A Revised Conceptual Model for YANG Datastores 14 draft-nmdsdt-netmod-revised-datastores-00 16 Abstract 18 Datastores are a fundamental concept binding the YANG data modeling 19 language to protocols transporting data defined in YANG data models, 20 such as NETCONF or RESTCONF. This document defines a revised 21 conceptual model of datastores based on the experience gained with 22 the initial simpler model and addressing requirements that were not 23 well supported in the initial model. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 30, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Original Model of Datastores . . . . . . . . . . . . . . . . 4 63 5. Revised Model of Datastores . . . . . . . . . . . . . . . . . 6 64 5.1. The datastore . . . . . . . . . . . . . . . . 8 65 5.2. The datastore . . . . . . . . . . . . . . . . . 8 66 5.2.1. Missing Resources . . . . . . . . . . . . . . . . . . 9 67 5.2.2. System-controlled Resources . . . . . . . . . . . . . 9 68 5.3. The datastore . . . . . . . . . . . . 9 69 6. Implications . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6.1. Implications on NETCONF . . . . . . . . . . . . . . . . . 9 71 6.1.1. Migration Path . . . . . . . . . . . . . . . . . . . 10 72 6.2. Implications on RESTCONF . . . . . . . . . . . . . . . . 10 73 6.3. Implications on YANG . . . . . . . . . . . . . . . . . . 11 74 6.4. Implications on Data Models . . . . . . . . . . . . . . . 11 75 7. Data Model Design Guidelines . . . . . . . . . . . . . . . . 11 76 7.1. Auto-configured or Auto-negotiated Values . . . . . . . . 11 77 8. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 81 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 12.2. Informative References . . . . . . . . . . . . . . . . . 15 84 Appendix A. Example Data . . . . . . . . . . . . . . . . . . . . 16 85 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 19 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 This document provides a revised architectural framework for 91 datastores as they are used by network management protocols such as 92 NETCONF [RFC6241], RESTCONF [I-D.ietf-netconf-restconf] and the YANG 93 [RFC7950] data modeling language. Datastores are a fundamental 94 concept binding management data models to network management 95 protocols and agreement on a common architectural model of datastores 96 ensures that data models can be written in a network management 97 protocol agnostic way. This architectural framework identifies a set 98 of conceptual datastores but it does not mandate that all network 99 management protocols expose all these conceptual datastores. 100 Furthermore, the architecture does not detail how data is encoded by 101 network management protocols. 103 2. Background 105 NETCONF [RFC6241] provides the following definitions: 107 o datastore: A conceptual place to store and access information. A 108 datastore might be implemented, for example, using files, a 109 database, flash memory locations, or combinations thereof. 111 o configuration datastore: The datastore holding the complete set of 112 configuration data that is required to get a device from its 113 initial default state into a desired operational state. 115 YANG 1.1 [RFC7950] provides the following refinements when NETCONF is 116 used with YANG (which is the usual case but note that NETCONF was 117 defined before YANG did exist): 119 o datastore: When modeled with YANG, a datastore is realized as an 120 instantiated data tree. 122 o configuration datastore: When modeled with YANG, a configuration 123 datastore is realized as an instantiated data tree with 124 configuration data. 126 RFC 6244 defined operational state data as follows: 128 o Operational state data is a set of data that has been obtained by 129 the system at runtime and influences the system's behavior similar 130 to configuration data. In contrast to configuration data, 131 operational state is transient and modified by interactions with 132 internal components or other systems via specialized protocols. 134 Section 4.3.3 of RFC 6244 discusses operational state and among other 135 things mentions the option to consider operational state as being 136 stored in another datastore. Section 4.4 of this document then 137 concludes that at the time of the writing, modeling state as a 138 separate data tree is the recommended approach. 140 Implementation experience and requests from operators 141 [I-D.ietf-netmod-opstate-reqs], [I-D.openconfig-netmod-opstate] 142 indicate that the datastore model initially designed for NETCONF and 143 refined by YANG needs to be extended. In particular, the notion of 144 intended configuration and applied configuration has developed. 146 Furthermore, separating operational state data from configuration 147 data in a separate branch in the data model has been found 148 operationally complicated. The relationship between the branches is 149 not machine readable and filter expressions operating on 150 configuration data and on related operational state data are 151 different. 153 3. Terminology 155 This document defines the following terms: 157 o configuration data: Data that determines how a device behaves. 158 Configuration data can originate from different sources. In YANG 159 1.1, configuration data is the "config true" nodes. 161 o static configuration data: Configuration data that is eventually 162 persistent and used to get a device from its initial default state 163 into its desired operational state. 165 o dynamic configuration data: Configuration data that is obtained 166 dynamically during the operation of a device through interaction 167 with other systems and not persistent. 169 o system configuration data: Configuration data that is supplied by 170 the device itself. 172 o data-model-defined configuration data: Configuration data that is 173 not explicitly provided but for which a value defined in the data 174 model is used. In YANG 1.1, such data can be defined with the 175 "default" statement or in "description" statements. 177 4. Original Model of Datastores 179 The following drawing shows the original model of datastores as it is 180 currently used by NETCONF [RFC6241]: 182 +-------------+ +-----------+ 183 | | | | 184 | (ct, rw) |<---+ +--->| (ct, rw) | 185 +-------------+ | | +-----------+ 186 | | | | 187 | +-----------+ | 188 +-------->| |<--------+ 189 | (ct, rw) | 190 +-----------+ 191 | 192 v 193 operational state <--- control plane 194 (cf, ro) 196 ct = config true; cf = config false 197 rw = read-write; ro = read-only 198 boxes denote datastores 200 Note that read-only (ro) and read-write (rw) is to be understood at a 201 conceptual level. In NETCONF, for example, support for the 202 and datastores is optional and the 203 datastore does not have to be writable. Furthermore, the 204 datastore can only be modified by copying to in 205 the standardized NETCONF datastore editing model. The RESTCONF 206 protocol does not expose these differences and instead provides only 207 a writable unified datastore, which hides whether edits are done 208 through a datastore or by directly modifying the 209 datastore or via some other implementation specific 210 mechanism. RESTCONF also hides how configuration is made persistent. 211 Note that implementations may also have additional datastores that 212 can propagate changes to the datastore. NETCONF explicitly 213 mentions so called named datastores. 215 Some observations: 217 o Operational state has not been defined as a datastore although 218 there were proposals in the past to introduce an operational state 219 datastore. 221 o The NETCONF operation returns the content of the 222 configuration datastore together with the operational state. It 223 is therefore necessary that config false data is in a different 224 branch than the config true data if the operational state data can 225 have a different lifetime compared to configuration data or if 226 configuration data is not immediately or successfully applied. 228 o Several implementations have proprietary mechanisms that allow 229 clients to store inactive data in the datastore; this 230 inactive data is only exposed to clients that indicate that they 231 support the concept of inactive data; clients not indicating 232 support for inactive data receive the content of the 233 datastore with the inactive data removed. Inactive data is 234 conceptually removed during validation. 236 o Some implementations have proprietary mechanisms that allow 237 clients to define configuration templates in . These 238 templates are expanded automatically by the system, and the 239 resulting configuration is applied internally. 241 o Some operators have reported that it is essential for them to be 242 able to retrieve the configuration that has actually been 243 successfully applied, which may be a subset or a superset of the 244 configuration. 246 5. Revised Model of Datastores 248 Below is a new conceptual model of datastores extending the original 249 model in order reflect the experience gained with the original model. 251 +-------------+ +-----------+ 252 | | | | 253 | (ct, rw) |<---+ +--->| (ct, rw) | 254 +-------------+ | | +-----------+ 255 | | | | 256 | +-----------+ | 257 +-------->| |<--------+ 258 | (ct, rw) | 259 +-----------+ 260 | 261 | // e.g., removal of 'inactive' 262 | // nodes, expansion of templates 263 v 264 +------------+ 265 | | // subject to validation 266 | (ct, ro) | 267 +------------+ 268 | 269 | // e.g., missing resources or 270 | // delays 271 v 272 +-----------+ 273 | |<---+--- dynamic configuration 274 | (ct, ro) | | protocols 275 +-----------+ +--- control-plane datastores 276 | 277 | +--- auto-discovery 278 | +-----+--- control-plane protocols 279 | | +--- control-plane datastores 280 v v 281 +---------------------+ 282 | | 283 | (ct + cf, ro) | 284 +---------------------+ 286 ct = config true; cf = config false 287 rw = read-write; ro = read-only 288 boxes denote datastores 290 The model foresees control-plane datastores that are by definition 291 not part of the persistent configuration of a device. In some 292 contexts, these have been termed ephemeral datastores since the 293 information is ephemeral, i.e., lost upon reboot. The control-plane 294 datastores interact with the rest of the system through the 295 or datastores, depending on the type of data they 296 contain. Note that the ephemeral datastore discussed in I2RS 297 documents maps to a control-plane datastore in the revised datastore 298 model described here. 300 5.1. The datastore 302 The datastore is a read-only datastore that consists of 303 config true nodes. It is tightly coupled to . When data is 304 written to , the data that is to be validated is also 305 conceptually written to . Validation is performed on the 306 contents of . 308 On a traditional NETCONF implementation, and are 309 always the same. 311 Currently there are no standard mechanisms defined that affect 312 so that it would have different contents than , 313 but this architecture allows for such mechanisms to be defined. 315 One example of such a mechanism is support for marking nodes as 316 inactive in . Inactive nodes are not copied to , 317 and are thus not taken into account when validating the 318 configuration. 320 Another example is support for templates. Templates are expanded 321 when copied into , and the result is validated. 323 5.2. The datastore 325 The datastore is a read-only datastore that consists of 326 config true nodes. It contains the currently active configuration on 327 the device. This data can come from several sources; from 328 , from dynamic configuration protocols (e.g., DHCP), or 329 from control-plane datastores. 331 As data flows into the and datastores, 332 it is conceptually marked with a metadata annotation ([RFC7952]) that 333 indicates its origin. The "origin" metadata annotation is defined in 334 Section 8. The values are YANG identities. The following identities 335 are defined: 337 +-- origin 338 +-- static 339 +-- dynamic 340 +-- data-model 341 +-- system 343 These identities can be further refined, e.g., there might be an 344 identity "dhcp" derived from "dynamic". 346 The datastore contains the subset of the instances in the 347 datastore where the "origin" values are derived 348 from or equal to "static" or "dynamic". 350 5.2.1. Missing Resources 352 Sometimes some parts of configuration refer to resources 353 that are not present and hence parts of the configuration 354 cannot be applied. A typical example is an interface configuration 355 that refers to an interface that is not currently present. In such a 356 situation, the interface configuration remains in but the 357 interface configuration will not appear in . 359 5.2.2. System-controlled Resources 361 Sometimes resources are controlled by the device and such system 362 controlled resources appear in (and disappear from) the 363 dynamically. If a system controlled resource has 364 matching configuration in when it appears, the system will 365 try to apply the configuration, which causes the configuration to 366 appear in eventually (if application of the configuration 367 was successful). 369 5.3. The datastore 371 The datastore is a read-only datastore that 372 consists of config true and config false nodes. In the original 373 NETCONF model the operational state only had config false nodes. The 374 reason for incorporating config true nodes here is to be able to 375 expose all operational settings without having to replicate 376 definitions in the data models. 378 The datastore contains all configura data 379 actually used by the system, i.e., all applied configuration, system 380 configuration and data-model-defined configuration. This data is 381 marked with the "origin" metadata annotation. In addition, the 382 datastore also contains state data. 384 In the datastore, semantic constraints defined in 385 the data model are not applied. See Appendix B. 387 6. Implications 389 6.1. Implications on NETCONF 391 o A mechanism is needed to announce support for , 392 , and . 394 o Support for , , and should 395 be optional to implement. 397 o For systems supporting or configuration 398 datastores, the operation may be used to retrieve 399 data stored in these new datastores. 401 o A new operation should be added to retrieve the operational state 402 data store (e.g., ). An alternative is to define a 403 new operation to retrieve data from any datastore (e.g., 404 with the name of the datastore as a parameter). In 405 principle could work but it would be a confusing 406 name. 408 o The operation will be deprecated since it returns data from 409 two datastores that may overlap in the revised datastore model. 411 6.1.1. Migration Path 413 A common approach in current data models is to have two separate 414 trees "/foo" and "/foo-state", where the former contains config true 415 nodes, and the latter config false nodes. A data model that is 416 designed for the revised architectural framework presented in this 417 document will have a single tree "/foo" with a combination of config 418 true and config false nodes. 420 A server that implements the datastore can 421 implement a module of the old design. In this case, some instances 422 are probably reported both in the "/foo" tree and in the "/foo-state" 423 tree. 425 A server that does not implement the datastore 426 can implement a module of the new design, but with limited 427 functionality. Specifically, it may not be possible to retrieve all 428 operationally used instances (e.g., dynamically configured or system- 429 controlled). The same limitation applies to a client that does not 430 implement the datastore, but talks to a server 431 that implements it. 433 6.2. Implications on RESTCONF 435 o The {+restconf}/data resource represents the combined 436 configuration and state data resources that can be accessed by a 437 client. This is effectively bundling together with 438 , much like the operation of NETCONF. 439 This design should be deprecated. 441 o A new query parameter is needed to indicate that data from 442 is requested. 444 6.3. Implications on YANG 446 o Some clarifications may be needed if this revised model is 447 adopted. YANG currently describes validation in terms of the 448 configuration datastore while it really happens on the 449 configuration datastore. 451 6.4. Implications on Data Models 453 o Since the NETCONF operation returns the content of the 454 configuration datastore and the operational state 455 together in one tree, data models were often forced to branch at 456 the top-level into a config true branch and a structurally similar 457 config false branch that replicated some of the config true nodes 458 and added state nodes. With the revised datastore model this is 459 not needed anymore since the different datastores handle the 460 different lifetimes of data objects. Introducing this model 461 together with the deprecation of the operation makes it 462 possible to write simpler models. 464 o There may be some differences in the value set of some nodes that 465 are used for both configuration and state. At this point of time, 466 these are considered to be rare cases that can be dealt with using 467 different nodes for the configured and state values. 469 o It is important to design data models with clear semantics that 470 work equally well for instantiation in a configuration datastore 471 and instantiation in the datastore. 473 7. Data Model Design Guidelines 475 7.1. Auto-configured or Auto-negotiated Values 477 Sometimes configuration leafs support special values that instruct 478 the system to automatically configure a value. An example is an MTU 479 that is configured to 'auto' to let the system determine a suitable 480 MTU value. Another example is Ethernet auto-negotiation of link 481 speed. In such a situation, it is recommended to model this as two 482 separate leafs, one config true leaf for the input to the auto- 483 negotiation process, and one config false leaf for the output from 484 the process. 486 8. Data Model 488 file "ietf-yang-architecture@2016-10-13.yang" 490 module ietf-yang-architecture { 491 namespace "urn:ietf:params:xml:ns:yang:ietf-yang-architecture"; 492 prefix arch; 494 import ietf-yang-metadata { 495 prefix md; 496 } 498 organization 499 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 501 contact 502 "WG Web: 504 WG List: 506 Editor: Martin Bjorklund 507 "; 509 description 510 "This YANG module defines an 'origin' metadata annotation, 511 and a set of identities for the origin value. The 'origin' 512 metadata annotation is used to mark data in the applied 513 and operational state datastores with information on where 514 the data originated. 516 Copyright (c) 2016 IETF Trust and the persons identified as 517 authors of the code. All rights reserved. 519 Redistribution and use in source and binary forms, with or 520 without modification, is permitted pursuant to, and subject to 521 the license terms contained in, the Simplified BSD License set 522 forth in Section 4.c of the IETF Trust's Legal Provisions 523 Relating to IETF Documents 524 (http://trustee.ietf.org/license-info). 526 This version of this YANG module is part of RFC XXXX 527 (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself 528 for full legal notices."; 530 revision 2016-10-13 { 531 description 532 "Initial revision."; 533 reference 534 "RFC XXXX: A Revised Conceptual Model for YANG Datastores"; 535 } 537 /* 538 * Identities 539 */ 541 identity origin { 542 description 543 "Abstract base identitiy for the origin annotation."; 544 } 546 identity static { 547 base origin; 548 description 549 "Denotes data from static configuration (e.g., )."; 550 } 552 identity dynamic { 553 base origin; 554 description 555 "Denotes data from dynamic configuration protocols 556 or dynamic datastores (e.g., DHCP)."; 557 } 559 identity system { 560 base origin; 561 description 562 "Denotes data created by the system independently of what 563 has been configured."; 564 } 566 identity data-model { 567 base origin; 568 description 569 "Denotes data that does not have an explicitly configured 570 value, but has a default value in use. Covers both simple 571 defaults and complex defaults."; 572 } 574 /* 575 * Metadata annotations 576 */ 578 md:annotation origin { 579 type identityref { 580 base origin; 581 } 583 } 585 } 587 589 9. IANA Considerations 591 TBD 593 10. Security Considerations 595 This document discusses a conceptual model of datastores for network 596 management using NETCONF/RESTCONF and YANG. It has no security 597 impact on the Internet. 599 11. Acknowledgments 601 This document grew out of many discussions that took place since 602 2010. Several Internet-Drafts ([I-D.bjorklund-netmod-operational], 603 [I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs], 604 [I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and 605 [RFC6244] touched on some of the problems of the original datastore 606 model. The following people were authors to these Internet-Drafts or 607 otherwise actively involved in the discussions that led to this 608 document: 610 o Lou Berger, LabN Consulting, L.L.C., 612 o Andy Bierman, YumaWorks, 614 o Marcus Hines, Google, 616 o Christian Hopps, Deutsche Telekom, 618 o Acee Lindem, Cisco Systems, 620 o Ladislav Lhotka, CZ.NIC, 622 o Thomas Nadeau, Brocade Networks, 624 o Anees Shaikh, Google, 626 o Rob Shakir, Google, 628 Juergen Schoenwaelder was partly funded by Flamingo, a Network of 629 Excellence project (ICT-318488) supported by the European Commission 630 under its Seventh Framework Programme. 632 12. References 634 12.1. Normative References 636 [I-D.ietf-netconf-restconf] 637 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 638 Protocol", draft-ietf-netconf-restconf-17 (work in 639 progress), September 2016. 641 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 642 and A. Bierman, Ed., "Network Configuration Protocol 643 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 644 . 646 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 647 RFC 7950, DOI 10.17487/RFC7950, August 2016, 648 . 650 [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", 651 RFC 7952, DOI 10.17487/RFC7952, August 2016, 652 . 654 12.2. Informative References 656 [I-D.bjorklund-netmod-operational] 657 Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF 658 and YANG", draft-bjorklund-netmod-operational-00 (work in 659 progress), October 2012. 661 [I-D.ietf-netmod-opstate-reqs] 662 Watsen, K. and T. Nadeau, "Terminology and Requirements 663 for Enhanced Handling of Operational State", draft-ietf- 664 netmod-opstate-reqs-04 (work in progress), January 2016. 666 [I-D.kwatsen-netmod-opstate] 667 Watsen, K., Bierman, A., Bjorklund, M., and J. 668 Schoenwaelder, "Operational State Enhancements for YANG, 669 NETCONF, and RESTCONF", draft-kwatsen-netmod-opstate-02 670 (work in progress), February 2016. 672 [I-D.openconfig-netmod-opstate] 673 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 674 of Operational State Data in YANG", draft-openconfig- 675 netmod-opstate-01 (work in progress), July 2015. 677 [I-D.wilton-netmod-opstate-yang] 678 Wilton, R., ""With-config-state" Capability for NETCONF/ 679 RESTCONF", draft-wilton-netmod-opstate-yang-02 (work in 680 progress), December 2015. 682 [RFC6244] Shafer, P., "An Architecture for Network Management Using 683 NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 684 2011, . 686 Appendix A. Example Data 688 In this example, the following fictional module is used: 690 module example-system { 691 yang-version 1.1; 692 namespace urn:example:system; 693 prefix sys; 695 import ietf-inet-types { 696 prefix inet; 697 } 699 container system { 700 leaf hostname { 701 type string; 702 } 704 list interface { 705 key name; 707 leaf name { 708 type string; 709 } 711 container auto-negotiation { 712 leaf enabled { 713 type boolean; 714 default true; 715 } 716 leaf speed { 717 type uint32; 718 units mbps; 719 description 720 "The advertised speed, in mbps."; 721 } 722 } 724 leaf speed { 725 type uint32; 726 units mbps; 727 config false; 728 description 729 "The speed of the interface, in mbps."; 730 } 732 list address { 733 key ip; 735 leaf ip { 736 type inet:ip-address; 737 } 738 leaf prefix-length { 739 type uint8; 740 } 741 } 742 } 743 } 744 } 746 The operator has configured the host name and two interfaces, so the 747 contents of is: 749 751 foo 753 754 eth0 755 756 1000 757 758
759 2001:db8::10 760 32 761
762 764 765 eth1 766
767 2001:db8::20 768 32 769
770 772 773 The system has detected that the hardware for one of the configured 774 interfaces ("eth1") is not yet present, so the configuration for that 775 interface is not applied. Further, the system has received a host 776 name and an additional IP address for "eth0" over DHCP. This is 777 reflected in : 779 783 bar 785 786 eth0 787 788 1000 789 790
791 2001:db8::10 792 32 793
794
795 2001:db8::1:100 796 32 797
798 800 802 In , all data from is present, in 803 addition to a default value, a loopback interface automatically added 804 by the system, and the result of the "speed" auto-negotiation: 806 810 bar 812 813 eth0 814 815 true 816 1000 817 818 100 819
820 2001:db8::10 821 32 822
823
824 2001:db8::1:100 825 32 826
827 829 830 lo0 831
832 ::1 833 128 834
835 837 839 Appendix B. Open Issues 841 1. Do we need another DS inbetween and 842 ? This DS would allow a client to see all active 843 nodes, including unexpanded templates. 845 2. How do we handle semantical constraints in ? 846 Are they just ignored? Do we need a new YANG statement to define 847 if a "must" constraints applies to the ? 849 3. Should it be possible to ask for in RESTCONF? 851 4. Better name for "static configuration"? 853 5. Better name for "intended"? 855 Authors' Addresses 857 Martin Bjorklund (editor) 858 Tail-f Systems 860 Email: mbj@tail-f.com 862 Juergen Schoenwaelder 863 Jacobs University 865 Email: j.schoenwaelder@jacobs-university.de 867 Phil Shafer 868 Juniper 870 Email: phil@juniper.net 872 Kent Watsen 873 Juniper 875 Email: kwatsen@juniper.net 877 Rob Wilton 878 Cisco 880 Email: rwilton@cisco.com