idnits 2.17.1 draft-hares-netmod-i2rs-yang-04.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 150 has weird spacing: '...tastore are c...' -- The document date (March 11, 2017) is 2603 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7950' is mentioned on line 988, but not defined == Missing Reference: 'RFC7921' is mentioned on line 983, but not defined == Missing Reference: 'RFC6241' is mentioned on line 978, but not defined == Missing Reference: 'RFC8044' is mentioned on line 992, but not defined == Missing Reference: 'RFC2119' is mentioned on line 973, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-i2rs-security-environment-reqs-03 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-00 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS working group S. Hares 3 Internet-Draft Huawei 4 Intended status: Informational A. Dass 5 Expires: September 12, 2017 Ericsson 6 March 11, 2017 8 Yang for I2RS Protocol 9 draft-hares-netmod-i2rs-yang-04.txt 11 Abstract 13 This document requests yang language additions for the data models 14 that exist as part of the I2RS control plane datastore. One of these 15 additions is the ability to mark a portion of the model as having 16 ephemeral state. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 12, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Requirements language . . . . . . . . . . . . . . . . . . 3 55 2.2. I2RS Definitions . . . . . . . . . . . . . . . . . . . . 3 56 3. yang additions . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. datastoredef . . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. datastore . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.3. dstype . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.4. ephemeral . . . . . . . . . . . . . . . . . . . . . . . . 9 61 3.5. module-list . . . . . . . . . . . . . . . . . . . . . . . 9 62 3.6. precedence . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.6.1. precedenceval . . . . . . . . . . . . . . . . . . . . 10 64 3.7. protosup statement . . . . . . . . . . . . . . . . . . . 10 65 3.7.1. protobase . . . . . . . . . . . . . . . . . . . . . . 11 66 3.7.2. protoadd . . . . . . . . . . . . . . . . . . . . . . 11 67 3.8. validation . . . . . . . . . . . . . . . . . . . . . . . 12 68 3.8.1. bulkcheck . . . . . . . . . . . . . . . . . . . . . . 13 69 3.8.2. caching . . . . . . . . . . . . . . . . . . . . . . . 13 70 3.8.3. nstransport . . . . . . . . . . . . . . . . . . . . . 14 71 4. Change to RFC7950 . . . . . . . . . . . . . . . . . . . . . . 14 72 4.1. Additions to the Module table . . . . . . . . . . . . . . 15 73 4.2. Additions to the submodule substatement list . . . . . . 16 74 4.3. Additions to the container substatement list . . . . . . 18 75 4.4. Additions to leaf substatement list . . . . . . . . . . . 18 76 4.5. Additions to leaf-list substatement list . . . . . . . . 19 77 4.6. Additions to list substatement list . . . . . . . . . . . 20 78 4.7. Additions to the grouping substatement table . . . . . . 21 79 4.8. Additions to the rpc substatement list . . . . . . . . . 22 80 4.9. Additions to the action substatement list . . . . . . . . 23 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 8.1. Normative References: . . . . . . . . . . . . . . . . . . 25 86 8.2. Informative References . . . . . . . . . . . . . . . . . 25 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 89 1. Introduction 91 This a proposal for additions to yang 1.1 [RFC7950] to support the 92 I2RS protocol. 94 The I2RS architecture [RFC7921] defines the I2RS interface "a 95 programmatic interface for state transfer in and out of the Internet 96 routing system". The I2RS protocol is a protocol designed to a 97 higher level protocol comprised of a set of IETF existing protocols 98 (NETCONF [RFC6241], RESTCONF [RFC8044], and others) which have been 99 extended to work together to support a new interface to the routing 100 system. The I2RS protocol is a "reuse" management protocol which 101 creates new management protocols by reusing existing protocols and 102 extending these protocols for new uses, and has been designed to be 103 implemented in phases [RFC7921]. 105 This document suggests the following additions to Yang to support the 106 I2RS control plane datastore. [I-D.ietf-i2rs-ephemeral-state] 107 specifies the I2RS requirements for the ephemeral state. 109 Section 3 of this document defines optional additions to yang 1.1 to 110 support I2RS ephemeral control plane datastore. The main addition is 111 the datastore statement with four new substatements (dstype, 112 ephemeral, protosup, validation). The protosup substatement has two 113 valid substatements (protobase, protoadd). The validation 114 substatement has has three new substatements: bulkchecks, caching, 115 and nstransport. 117 Section 4 provides the augmentation to RFC7950 tables for these 118 optional features. 120 2. Definitions 122 2.1. Requirements language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 2.2. I2RS Definitions 130 The I2RS architecture [RFC7921] defines the following terms: 132 ephemeral data: is data which does not persist across a reboot 133 (software or hardware) or a power on/off condition. Ephemeral 134 data can be configured data or data recorded from operations of 135 the router. Ephemeral configuration data also has the property 136 that a system cannot roll back to a previous ephemeral 137 configuration state. (See [RFC7921] for an architectural 138 overview, [I-D.ietf-i2rs-ephemeral-state] for requirements, and 139 [I-D.ietf-netmod-revised-datastores] for discussion of how the 140 ephemeral datastore as a control plane datastore interacts with 141 intended configuration datstore, the dynamic configuration 142 protocols, and control planes datastore to create the applied 143 datastore and operational state datastore. 145 local configuration: is the data on a routing system which does 146 persist across a reboot (software or hardware) and a power on/off 147 condition. Local configuration is defined as the intended 148 datastore as defined in [I-D.ietf-netmod-revised-datastores]. 150 dynamic configuration protocols datastore are configuration 151 protocols such as DHCP that interact with the intended datastore 152 (which does persist across a reboot (software or hardware) power 153 on/off condition), and the I2RS ephemeral state control plane 154 datastore. 156 applied datastore Read only datastore regarding configuration 157 state installed in the routing system as defined in 158 [I-D.ietf-netmod-revised-datastores]. 160 operational state Read only datastore that combines applied 161 datastore and operational state as defined in 162 [I-D.ietf-netmod-revised-datastores]. 164 operator-applied policy: is a policy that an operator sets that 165 determines how the ephemeral datastore as a control plane data 166 store interacts with intended configuration (see 167 [I-D.ietf-netmod-revised-datastores]). This operator policy 168 consists of setting a priority for each of the following (per 169 [I-D.ietf-i2rs-ephemeral-state]): 171 * intended configuration, 173 * any dynamic configuration protocols, 175 * any control plane datastores (one of which is ephemeral.) 177 3. yang additions 179 3.1. datastoredef 181 The "datastoredef" is a statement that defines a datastore provides 182 the ability to describe which datastore a module or submodule may be 183 loaded into. Each datastore statement must refer to a name defined 184 in a datastoredef statement. 186 The new substatements for the datstoredef command are dstype, 187 ephemeral, module-list, precedence, protosup, and validation. The 188 dstype provides information on the type of the datastore. The 189 ephemeral flag indicates the datastore is ephemeral. The module-list 190 provides a list of modules included in this datastore. the protosup 191 indicates the protocol support for this datastore, and the validation 192 provides information on the validation. 194 The "dsname" must be MUST be a nmae registered with IANA (see 195 [I-D.ietf-netmod-revised-datastores]). 197 Data store syntax: 199 datastoredef { 200 201 }; 203 dsname - Must be registered name for datastore 205 Figure 1 207 The substatements for the datastore substatement are listed below: 209 Table 1 210 +---------------+----------+---------+-------------+ 211 | | This | | | 212 | | document | RFC7960 | | 213 | substatement | section | section | cardinality | 214 +---------------+----------+---------+-------------+ 215 | description | - | 7.21.3 | 0..1 | 216 | dstype | 3.3 | - | 1 | 217 | ephemeral | 3.4 | - | 0..n | 218 | module | | 7.1 | 0..n | 219 | module-list | 3.5 | - | 0..n | 220 | organization | - | 7.1.7 | 0..1 | 221 | precedence | 3.6 | - | 0..n | 222 | protosup | 3.7 | - | 0..n | 223 | reference | - | 7.21.4 | 0..1 | 224 | revision | - | 7.1.9 | 0..n | 225 | revision-date | - | 7.1.5.1 | 0..1 | 226 | validation | 3.8 | - | 0..n | 227 | version | | 7.1.9 | 0..n | 228 +---------------+----------+---------+-------------+ 230 Note:There is a variance with ephemeral control-plane datastore 231 example in [I-D.ietf-netmod-revised-datastores] which uses "module" 232 to define a datastore rather than datastore. Rather than assume the 233 "module" will be re-used this document uses "datastoredef". 235 Example of use: 237 datastoredef i2rs-agent { 238 dstype control-plane; 239 description {"I2RS Agent datastore "}; 240 ephemeral true; 241 module-list ietf-i2rs-rib, ietf-network, ietf-network-topology, 242 ietf-l3-unicast-topology; 243 protosup { 244 protobase netconf; 245 protoadd control-plane; 246 protoadd ephemeral; 247 } 248 precedence applied { 249 precedenceval 5; //set to high value// 250 } 251 precedence opstate { 252 precedence 5; //set to high value// 253 } 254 revision 0.0; 255 version 1.0; 257 } 259 3.2. datastore 261 The "datastore" can be a substatement for the Yang Module statement 262 provides the ability to describe which datastore a module or 263 submodule may be loaded into. If no "datastore" statement exists, 264 there is no restriction on the datastores a module or submodule can 265 be loaded into. 267 The argument the datastore is a datastore name denoted as "dsname". 268 The "dsname" must be MUST be a nmae registered with IANA (see 269 [I-D.ietf-netmod-revised-datastores]). 271 The vaid substatements for the datastore statement are in Table 1. 272 The "description" substatement provides a description of the 273 datastore. The "dstype" provides information on the class (e.g., 274 config or control plane) and the subclass of the datastore (e.g., 275 i2rs). The ephemeral indicates that entire datastore is ephemeral. 276 The validation provides alternate validation rules for the datastore. 278 Data store syntax: 280 datastore { 281 282 }; 284 dsname - must be defined in a datastoredef statement 286 Figure 2 288 The substatements for the datastore substatement are listed below: 290 Table 2 291 +---------------+----------+---------+-------------+ 292 | | This | | | 293 | | document | RFC7960 | | 294 | substatement | section | section | cardinality | 295 +---------------+----------+---------+-------------+ 296 | description | - | 7.21.3 | 0..1 | 297 | dstype | 3.4 | - | 1 | 298 | ephemeral | 3.5 | - | 0..n | 299 | protosup | 3.7 | - | 0..n | 300 | reference | - | 7.21.4 | 0..1 | 301 | revision | - | 7.1.9 | 0..n | 302 | revision-date | - | 7.1.5.1 | 0..1 | 303 | validation | 3.8 | - | 0..n | 304 | version | | 7.1.9 | 0..n | 305 +---------------+----------+---------+-------------+ 307 Application Comments: 309 A module may be mounted into different datastores. The datastore 310 statement indicates which datastores a module may be mounted in, and 311 the characteristics of each datastore. 313 Example of use where a module is utilized 314 in two different datastores. 316 module ietf-i2rs-rib { 317 yang-version 1.1; 318 namespace "urn:ietf:params:xml:ns:yang:ietf-i2rs-rib"; 319 // replace with iana namespace when assigned 320 prefix "iir"; 321 import ietf-inet-types { 322 prefix inet; 323 //rfc6991 324 } 325 .... 326 organization 327 "IETF I2RS (Interface to Routing System) Working Group"; 328 .... 330 datastore i2rs-agent { 331 dstype "control-plane" "i2rs-vo"; 332 ephemeral true; 333 protosup { 334 protobase netconf; 335 protoadd control-plane; 336 protoadd ephemeral; 337 } 338 } 339 datastore config { 340 dstype config; 341 ephemeral false; 342 protosup { 343 protobase restconf; 344 } 345 protosup { 346 protobase netconf; 347 } 348 } 350 } 352 3.3. dstype 354 They substatement dstype indicates the datastore class and subclass 355 of the datastore. A dstype substatement may only exist within a 356 datastore statement. 358 Syntax of the dstype datastore is: 360 dstype ; 362 where: 363 dsclass: ["config" | "control-plane ] 364 dssubclass [ "i2rs-v0" ] 366 Figure 3 368 3.4. ephemeral 370 The ephemeral indicates that an object is ephemeral data which does 371 not survive a reboot (see [I-D.ietf-i2rs-ephemeral-state]). The 372 definition of the object may be a datastore, a module, a submodule, 373 an action, a container, a grouping, a leaf, a leaf-list, a list, or 374 an rpc. 376 Syntax is the following: 377 ephemeral [true | false]; 379 The value "true" indicates the object is not ephemeral. 380 The value "false" indicates the value is ephemeral. 382 Figure 4 384 Note: There is a variance with ephemeral functionality with 385 [I-D.ietf-netmod-revised-datastores]. Rather than consider the 386 keyword ephemeral as a identity, this proposes ephemeral will be a 387 yang substatement. 389 3.5. module-list 391 The module list contains a list of module names. 393 Syntax is the following: 394 module-list , .... ; 396 Each name on the list (e.g. ) 397 must be a name in a module statement. 399 Figure 5 401 3.6. precedence 403 The precedence provides the value for precedence insertion of the 404 datastores (the precedence substatement is contained) versus the 405 datastore "dsname". Examples of datastore can be applied, opstate, 406 or other control plane datastores. If no precedence is statement is 407 given, the configuration datastore takes precedence. 409 The module-list restricts this precedence for just these modules. A 410 submodule must belong to one of the modules in the module list, and 411 it further restricts the precedence value to just the submodule 412 within the module. 414 Syntax is the following: 416 precedence [applied | opstate | ] { 417 <> 418 }; 420 dsname - registered name for datastore 422 Figure 6 424 Table 3 425 +---------------+----------+---------+-------------+ 426 | | document | RFC7960 | | 427 | substatement | section | section | cardinality | 428 +---------------+----------+---------+-------------+ 429 | description | - | 7.21.3 | 0..1 | 430 | module-list | 3.x | - | 0..n | 431 | precedenceval | 3.x | - | 1 | 432 | sub-modules | | 7.2 | 0..n | 433 +---------------+----------+---------+-------------+ 435 3.6.1. precedenceval 437 The precedenceval provides the value for precedence. 439 Syntax is the following: 441 precedenceval ; 443 ; - is the integer value for precedence. 445 Figure 7 447 3.7. protosup statement 449 This indicates which protocols support this datastore. The protocols 450 can be netconf, restconf, coap, gprc, and bgp. The substatements for 451 protosup are protocobase and protoadd 452 Syntax is the following: 453 protosup { 454 <> 455 } 457 Figure 8 459 Table 4 460 +---------------+----------+---------+-------------+ 461 | | document | RFC7960 | | 462 | substatement | section | section | cardinality | 463 +---------------+----------+---------+-------------+ 464 | description | - | 7.21.3 | 0..1 | 465 | protobase | 3.4.1 | - | 1..n | 466 | protoadd | 3.4.2 | - | 1..n | 467 +---------------+----------+---------+-------------+ 469 3.7.1. protobase 471 The protobase substatement indicates the protocol a database can be 472 sent over. The syntax is below: 474 Syntax for protobase: 476 protobase [netconf | restconf | coap 477 | bgp | isis | ospf | dots 478 | ] 480 Where protocolo-name is one of protocol names 481 registered by IANA. 482 Figure 9 484 3.7.2. protoadd 486 The protoadd specifies required optional additions to a protocol that 487 sends information to a datastore. One example of such an addition is 488 the additions to RESTCONF to support the I2RS protocol denoted as 489 "i2rs". 491 Syntax for proto add: 493 protoadd [control-plane | i2rs | i2nsf | 494 | ephemeral | ] 496 Figure 10 498 The protocol additions is the name of a capability or grouping of 499 capabilities for support. For example, the "i2rs" capability is a 500 capability which combines the capabilities the "control-plane" 501 netconf capability with the netconf ephemeral capability. 503 3.8. validation 505 The validation keyword indicates that the object uses alternate 506 validation besides the mechanisms defined by the configuration 507 datastore as defined in [RFC7950]. The validation subcommand is 508 invalid in any module or submodule which is only defined for the 509 configuration datastore. Unless the module has a datastore statement 510 which includes a datastore other than config, all validation 511 statements in the module are ignored. Unless the submodule has a 512 datastore statement which includes a datastore other than config, all 513 validation statements are ignored. 515 The validation can be set on a datastore command in a a module, a 516 submodule, an action, a container, a grouping, a leaf, a leaf-list, a 517 list, or an rpc. The validation substatements include nstransport 518 and bulk-checks as shown in table 3. 520 Syntax of the validation is: 521 validation { 522 <> 523 }; 525 Figure 11 526 Table 5 527 +---------------+----------+---------+-------------+ 528 | | document | RFC7960 | | 529 | substatement | section | section | cardinality | 530 +---------------+----------+---------+-------------+ 531 | description | - | 7.21.3 | 0..1 | 532 | bulkchecks | 3.8.1 | - | 0..1 | 533 | caching | 3.8.2 | - | 0..1 | 534 | nstransport | 3.8.3 | - | 0..1 | 535 | organization | - | 7.1.7 | 0..1 | 536 | reference | - | 7.21.4 | 0..n | 537 | revision-date | - | 7.1.5.1 | 0..1 | 538 | version | | 7.1.9 | 0..n | 539 +---------------+----------+---------+-------------+ 541 3.8.1. bulkcheck 543 The bulkcheck flag indicates whether this object uses bulk-check 544 validation instead of the normal configuration datastore validation. 545 The protocol updating the object must support bulk checking 546 mechanism, or indicate that this object is not supported. 548 This is a new feature for control plane protocols and control plane 549 datastores. In the configuration datastores, it is possible to 550 support this feature at the validation level for the rpc object. 551 Early implemementers of this feature for module which may loaded in 552 the configuration datastore are encouraged to place bulkcheck 553 features within "rpc" functionality. 555 bulkcheck syntax: 557 bulkchecks [yes | no]; 559 Figure 12 561 The value "no" indicates the object does not allows "bulkchecks" of 562 data, and uses the normal configuration datastore checking. The 563 value "yes" indicates the object does not allows "bulkchecks" of data 564 within this object. 566 3.8.2. caching 568 The caching flag indicates whether the I2RS support caching of 569 multiple client information within I2RS Agents. 571 Application note: This feature is not supported for the I2RS protocol 572 version 0 573 caching syntax: 575 caching [yes | no]; 577 Figure 13 579 The value "no" indicates the object does not allows "bulkchecks" of 580 data, and uses the normal configuration datastore checking. The 581 value "yes" indicates the object does not allows "bulkchecks" of data 582 within this object. 584 3.8.3. nstransport 586 The nstransport indicates whether this object may be sent across a 587 non-secure transport. Sending data across a non-secure transport 588 should be done only if the circumstances warrant it. 590 This is a new feature for the I2RS control plane protocols and 591 control plane datastores. 593 Caution: For a description of when a on-secure transport is 594 appropriate for I2RS control plane protocol, please refer to the I2RS 595 protocol security requirements 596 [I-D.ietf-i2rs-protocol-security-requirements]. Implementers of this 597 feature in an I2RS implementation should also review the I2RS 598 security requirements [I-D.ietf-i2rs-security-environment-reqs]. No 599 data which reveals any identity for a person or confidential 600 information should be sent via a non-secure transport. 602 Syntax is the following: 604 nstransport [yes | no]; 606 Figure 14 608 The value "no" indicates the object does not allows "bulkchecks" of 609 data, and uses the normal configuration datastore checking. The 610 value "yes" indicates the object does not allows "bulkchecks" of data 611 within this object. 613 4. Change to RFC7950 615 The optional attributes add options to the tables for substatements 616 for the module (section 7.1.1), submodule table, action, container, 617 grouping, leaf, leaf-list, a list, and an rpc. This section provides 618 the revised tables. 620 4.1. Additions to the Module table 622 This is the additions to module's substatment table in section 7.1.1 623 of [RFC7950]. 625 7.1.1 substatement (replacement) 626 +--------------+----------+-------------+ 627 | | RFC7950 | | 628 | substatement | section | cardinality | 629 +--------------+----------+-------------+ 630 | anydata | 7.10 | 0..n | 631 | anyxml | 7.11 | 0..n | 632 | augment | 7.17 | 0..n | 633 | choice | 7.9 | 0..n | 634 | contact | 7.1.8 | 0..1 | 635 | container | 7.5 | 0..n | 636 | description | 7.21.3 | 0..1 | 637 | deviation | 7.20.3 | 0..n | 638 | extension | 7.19 | 0..n | 639 | feature | 7.20.1 | 0..n | 640 | grouping | 7.12 | 0..n | 641 | identity | 7.18 | 0..n | 642 | import | 7.1.5 | 0..n | 643 | include | 7.1.6 | 0..n | 644 | leaf | 7.6 | 0..n | 645 | leaf-list | 7.7 | 0..n | 646 | list | 7.8 | 0..n | 647 | namespace | 7.1.3 | 1 | 648 | notification | 7.16 | 0..n | 649 | organization | 7.1.7 | 0..1 | 650 | prefix | 7.1.4 | 1 | 651 | reference | 7.21.4 | 0..1 | 652 | revision | 7.1.9 | 0..n | 653 | rpc | 7.14 | 0..n | 654 | typedef | 7.3 | 0..n | 655 | uses | 7.13 | 0..n | 656 | yang-version | 7.1.2 | 1 | 657 +--------------+----------+-------------+ 658 | optional | This | | 659 | Yang 1.1 |document's| | 660 | substatement | section | cardinality | 661 +--------------+----------+-------------+ 662 | datastore | 3.2 | 0..n | 663 | ephemeral | 3.4 | 0..n | 664 | validation | 3.8 | 0..n | 665 +--------------+----------+-------------+ 667 4.2. Additions to the submodule substatement list 669 Below would be the replacement for the substatement table in setion 670 7.2.1 of [RFC7950] which lists the valid submodule statements. 672 7.2.1. The submodule's Substatements (replcement) 674 +--------------+----------+-------------+ 675 | | RFC7950 | | 676 | substatement | section | cardinality | 677 +--------------+----------+-------------+ 678 | anydata | 7.10 | 0..n | 679 | anyxml | 7.11 | 0..n | 680 | augment | 7.17 | 0..n | 681 | belongs-to | 7.2.2 | 1 | 682 | choice | 7.9 | 0..n | 683 | contact | 7.1.8 | 0..1 | 684 | container | 7.5 | 0..n | 685 | description | 7.21.3 | 0..1 | 686 | deviation | 7.20.3 | 0..n | 687 | extension | 7.19 | 0..n | 688 | feature | 7.20.1 | 0..n | 689 | grouping | 7.12 | 0..n | 690 | identity | 7.18 | 0..n | 691 | import | 7.1.5 | 0..n | 692 | include | 7.1.6 | 0..n | 693 | leaf | 7.6 | 0..n | 694 | leaf-list | 7.7 | 0..n | 695 | list | 7.8 | 0..n | 696 | namespace | 7.1.3 | 1 | 697 | notification | 7.16 | 0..n | 698 | organization | 7.1.7 | 0..1 | 699 | reference | 7.21.4 | 0..1 | 700 | revision | 7.1.9 | 0..n | 701 | rpc | 7.14 | 0..n | 702 | typedef | 7.3 | 0..n | 703 | uses | 7.13 | 0..n | 704 | yang-version | 7.1.2 | 1 | 705 +--------------+----------+-------------+ 706 | optional | This | | 707 | Yang 1.1 |document's| | 708 | substatement | section | cardinality | 709 +--------------+----------+-------------+ 710 | ephemeral | 3.4 | 0..n | 711 | validation | 3.8 | 0..n | 712 +--------------+----------+-------------+ 714 4.3. Additions to the container substatement list 716 Below would be the replacement for the substatement table in section 717 7.5.2 of [RFC7950] that lists the legal container substatements. 719 7.5.2. The container Substatements (replacement) 721 +--------------+----------+-------------+ 722 | | RFC7950 | | 723 | substatement | section | cardinality | 724 +--------------+----------+-------------+ 725 | action | 7.15 | 0..n | 726 | anydata | 7.10 | 0..n | 727 | anyxml | 7.11 | 0..n | 728 | choice | 7.9 | 0..n | 729 | config | 7.21.1 | 0..1 | 730 | description | 7.21.3 | 0..1 | 731 | grouping | 7.12 | 0..n | 732 | if-feature | 7.20.2 | 0..n | 733 | leaf | 7.6 | 0..n | 734 | leaf-list | 7.7 | 0..n | 735 | list | 7.8 | 0..n | 736 | must | 7.5.3 | 0..n | 737 | notification | 7.16 | 0..n | 738 | presennce | 7.5.5 | 0..1 | 739 | reference | 7.21.4 | 0..1 | 740 | status | 7.1.9 | 0..1 | 741 | typedef | 7.3 | 0..n | 742 | uses | 7.13 | 0..n | 743 | when | 7.21.5 | 0..1 | 744 +--------------+----------+-------------+ 745 | optional | This | | 746 | Yang 1.1 |document's| | 747 | substatement | section | cardinality | 748 +--------------+----------+-------------+ 749 | ephemeral | 3.4 | 0..n | 750 | validation | 3.8 | 0..n | 751 +--------------+----------+-------------+ 753 4.4. Additions to leaf substatement list 755 Below would be replacement for the substatement table in section 756 7.6.2 of [RFC7950] which provides the leaf's substatements. 758 7.6.2 The leaf's Substatements (replacement) 760 +--------------+----------+-------------+ 761 | | RFC7950 | | 762 | substatement | section | cardinality | 763 +--------------+----------+-------------+ 764 | config | 7.21.1 | 0..1 | 765 | default | 7.6.4 | 0..1 | 766 | description | 7.21.3 | 0..1 | 767 | if-feature | 7.20.2 | 0..n | 768 | mandatory | 7.6.5 | 0..1 | 769 | must | 7.5.3 | 0..n | 770 | reference | 7.21.4 | 0..1 | 771 | status | 7.21.2 | 0..1 | 772 | type | 7.6.3 | 1 | 773 | units | 7.3.3 | 0..1 | 774 | when | 7.21.5 | 0..1 | 775 +--------------+----------+-------------+ 776 | optional | This | | 777 | Yang 1.1 |document's| | 778 | substatement | section | cardinality | 779 +--------------+----------+-------------+ 780 | ephemeral | 3.4 | 0..n | 781 | validation | 3.8 | 0..n | 782 +--------------+----------+-------------+ 784 4.5. Additions to leaf-list substatement list 786 Below would be the replacement for the substatement table in section 787 7.7.2 in [RFC7950] which provides the list of the leaf-lists 788 substatements. 790 7.7.2 The leaf's Substatements (replacement) 792 +--------------+----------+-------------+ 793 | | RFC7950 | | 794 | substatement | section | cardinality | 795 +--------------+----------+-------------+ 796 | config | 7.21.1 | 0..1 | 797 | default | 7.6.4 | 0..1 | 798 | description | 7.21.3 | 0..1 | 799 | if-feature | 7.20.2 | 0..n | 800 | max-elements | 7.7.6 | 0..1 | 801 | min-elements | 7.7.5 | 0..1 | 802 | must | 7.5.3 | 0..n | 803 | ordered-by | 7.7.7 | 0..1 | 804 | reference | 7.21.4 | 0..1 | 805 | status | 7.21.2 | 0..1 | 806 | type | 7.6.3 | 1 | 807 | units | 7.3.3 | 0..1 | 808 | when | 7.21.5 | 0..1 | 809 +--------------+---------+-------------+ 810 | optional | This | | 811 | Yang 1.1 |document's| | 812 | substatement | section | cardinality | 813 +--------------+----------+-------------+ 814 | ephemeral | 3.4 | 0..n | 815 | validation | 3.8 | 0..n | 816 +--------------+----------+-------------+ 818 4.6. Additions to list substatement list 820 Below would be the replacement for the table in section 7.8.1 in 821 [RFC7950] which provides the list's substatements. 823 7.8.1 The list's Substatements (replacement) 825 +--------------+----------+-------------+ 826 | | RFC7950 | | 827 | substatement | section | cardinality | 828 +--------------+----------+-------------+ 829 | action | 7.15 | 0..n | 830 | anydata | 7.10 | 0..n | 831 | anyxml | 7.11 | 0..n | 832 | choice | 7.9 | 0..n | 833 | config | 7.21.1 | 0..1 | 834 | container | 7.5 | 0..n | 835 | description | 7.21.3 | 0..1 | 836 | grouping | 7.12 | 0..n | 837 | if-feature | 7.20.2 | 0..n | 838 | key | 7.8.2 | 0..n | 839 | leaf | 7.6 | 0..n | 840 | leaf-list | 7.7 | 0..n | 841 | list | 7.8 | 0..n | 842 | max-elements | 7.7.6 | 0..1 | 843 | min-elements | 7.7.5 | 0..1 | 844 | must | 7.5.3 | 0..n | 845 | notification | 7.16 | 0..n } 846 | ordered-by | 7.7.7 | 0..1 | 847 | reference | 7.21.4 | 0..1 | 848 | status | 7.21.2 | 0..1 | 849 | typedef | 7.3 | 0..n | 850 | uses | 7.13 | 0..n | 851 | when | 7.21.5 | 0..1 | 852 +--------------+----------+-------------+ 853 | optional | This | | 854 | Yang 1.1 |document's| | 855 | substatement | section | cardinality | 856 +--------------+----------+-------------+ 857 | ephemeral | 3.4 | 0..n | 858 | validation | 3.8 | 0..n | 859 +--------------+----------+-------------+ 861 4.7. Additions to the grouping substatement table 863 Below would be the replacement for the table 7.12.1 of [RFC7950] that 864 lists the vaid substatments for the container substatements. 866 7.12.1. The grouping's Substatements (replacement) 868 +--------------+----------+-------------+ 869 | | RFC7950 | | 870 | substatement | section | cardinality | 871 +--------------+----------+-------------+ 872 | action | 7.15 | 0..n | 873 | anydata | 7.10 | 0..n | 874 | anyxml | 7.11 | 0..n | 875 | choice | 7.9 | 0..n | 876 | description | 7.21.3 | 0..1 | 877 | grouping | 7.12 | 0..n | 878 | leaf | 7.6 | 0..n | 879 | leaf-list | 7.7 | 0..n | 880 | list | 7.8 | 0..n | 881 | notification | 7.16 | 0..n | 882 | reference | 7.21.4 | 0..1 | 883 | status | 7.1.9 | 0..1 | 884 | typedef | 7.3 | 0..n | 885 | uses | 7.13 | 0..n | 886 +--------------+----------+-------------+ 887 | optional | This | | 888 | Yang 1.1 |document's| | 889 | substatement | section | cardinality | 890 +--------------+----------+-------------+ 891 | ephemeral | 3.4 | 0..n | 892 | validation | 3.8 | 0..n | 893 +--------------+----------+-------------+ 895 4.8. Additions to the rpc substatement list 897 Below would be the replacement for the table in section 7.14.1 of 898 [RFC7950] that lists the legal rpc substatements. 900 7.5.2. The rpc Substatements 902 +--------------+----------+-------------+ 903 | | RFC7950 | | 904 | substatement | section | cardinality | 905 +--------------+----------+-------------+ 906 | description | 7.21.3 | 0..1 | 907 | grouping | 7.12 | 0..n | 908 | if-feature | 7.20.2 | 0..n | 909 | input | 7.14.2 | 0..1 | 910 | output | 7.14.3 | 0..1 | 911 | reference | 7.21.4 | 0..1 | 912 | status | 7.1.9 | 0..1 | 913 | typedef | 7.3 | 0..n | 914 +--------------+=---------+-------------+ 915 | optional | This | | 916 | Yang 1.1 |document's| | 917 | substatement | section | cardinality | 918 +--------------+----------+-------------+ 919 | ephemeral | 3.4 | 0..n | 920 | validation | 3.8 | 0..n | 921 +--------------+----------+-------------+ 923 4.9. Additions to the action substatement list 925 Below would be the replacement for the table 7.15.1 of [RFC7950] that 926 lists the legal action substatements. 928 7.5.2. The action Substatements 930 +--------------+----------+-------------+ 931 | | RFC7950 | | 932 | substatement | section | cardinality | 933 +--------------+----------+-------------+ 934 | description | 7.21.3 | 0..1 | 935 | grouping | 7.12 | 0..n | 936 | if-feature | 7.20.2 | 0..n | 937 | input | 7.14.2 | 0..1 | 938 | output | 7.14.3 | 0..1 | 939 | reference | 7.21.4 | 0..1 | 940 | status | 7.1.9 | 0..1 | 941 | typedef | 7.3 | 0..n | 942 +--------------+=---------+-------------+ 943 | optional | This | | 944 | Yang 1.1 |document's| | 945 | substatement | section | cardinality | 946 +--------------+----------+-------------+ 947 | ephemeral | 3.4 | 0..n | 948 | validation | 3.8 | 0..n | 949 +--------------+----------+-------------+ 951 Figure 2 953 5. IANA Considerations 955 The additions for registries go here. 957 6. Security Considerations 959 The security requirements for the I2RS protocol are covered in 960 [I-D.ietf-i2rs-protocol-security-requirements]. The security 961 environment the I2RS protocol is covered in 962 [I-D.ietf-i2rs-security-environment-reqs]. Any person implementing 963 or deploying these yang additions for an I2RS protocol should 964 consider both security requirements. 966 7. Acknowledgements 968 tBD 970 8. References 971 8.1. Normative References: 973 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 974 Requirement Levels", BCP 14, RFC 2119, 975 DOI 10.17487/RFC2119, March 1997, 976 . 978 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 979 and A. Bierman, Ed., "Network Configuration Protocol 980 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 981 . 983 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 984 Nadeau, "An Architecture for the Interface to the Routing 985 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 986 . 988 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 989 RFC 7950, DOI 10.17487/RFC7950, August 2016, 990 . 992 [RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044, 993 DOI 10.17487/RFC8044, January 2017, 994 . 996 8.2. Informative References 998 [I-D.ietf-i2rs-ephemeral-state] 999 Haas, J. and S. Hares, "I2RS Ephemeral State 1000 Requirements", draft-ietf-i2rs-ephemeral-state-23 (work in 1001 progress), November 2016. 1003 [I-D.ietf-i2rs-protocol-security-requirements] 1004 Hares, S., Migault, D., and J. Halpern, "I2RS Security 1005 Related Requirements", draft-ietf-i2rs-protocol-security- 1006 requirements-17 (work in progress), September 2016. 1008 [I-D.ietf-i2rs-security-environment-reqs] 1009 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 1010 Security Requirements", draft-ietf-i2rs-security- 1011 environment-reqs-03 (work in progress), March 2017. 1013 [I-D.ietf-netmod-revised-datastores] 1014 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1015 and R. Wilton, "A Revised Conceptual Model for YANG 1016 Datastores", draft-ietf-netmod-revised-datastores-00 (work 1017 in progress), December 2016. 1019 Authors' Addresses 1021 Susan Hares 1022 Huawei 1023 Saline 1024 US 1026 Email: shares@ndzh.com 1028 Amit Daas 1029 Ericsson 1031 Email: amit.dass@ericsson.com