idnits 2.17.1 draft-claise-opsawg-service-assurance-yang-01.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 47 instances of too long lines in the document, the longest one being 27 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 4, 2019) is 1628 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG B. Claise 3 Internet-Draft J. Quilbeuf 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: May 7, 2020 November 4, 2019 7 YANG Modules for Service Assurance 8 draft-claise-opsawg-service-assurance-yang-01 10 Abstract 12 This document proposes YANG modules for the Service Assurance for 13 Intent-based Networking Architecture. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on May 7, 2020. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3 52 4. Base ietf-service-assurance YANG module . . . . . . . . . . . 4 53 4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Subservice Extension: ietf-service-assurance-device YANG 57 module . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 58 5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 11 59 5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 11 60 5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 12 61 5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13 62 6. Vendor-specific Subservice Extension: example-service- 63 assurance-device-acme YANG module . . . . . . . . . . . . . . 14 64 6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 14 65 6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 14 66 6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 15 67 6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 15 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 70 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 18 71 8.2. The YANG Module Names Registry . . . . . . . . . . . . . 18 72 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 75 10.2. Informative References . . . . . . . . . . . . . . . . . 19 76 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 79 1. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 83 "OPTIONAL" in this document are to be interpreted as described in BCP 84 14 [RFC2119] [RFC8174] when, and only when, they appear in all 85 capitals, as shown here. 87 The terms used in this document are defined in draft-claise-opsawg- 88 service-assurance-architecture IETF draft. 90 The terms used in this document are defined in 91 [draft-claise-opsawg-service-assurance-architecture]. 93 2. Introduction 95 The "Service Assurance for Intent-based Networking Architecture" 96 document [draft-claise-opsawg-service-assurance-architecture], 97 specifies the framework and all of its components for service 98 assurance. This document complements the architecture by providing 99 open interfaces between components. More specifically, the goal is 100 to provide YANG modules for the purpose of service assurance in a 101 format that is: 103 o formal 105 o vendor independent 107 o augmentable 109 3. YANG Models Overview 111 The main YANG module, ietf-service-assurance, defines objects for 112 assuring network services based on their decomposition into so-called 113 subservices. The subservices are hierarchically organised by 114 dependencies. The subservices, along with the dependencies, 115 constitute an assurance tree. This module should be supported by an 116 agent, able to interact with the devices in order to produce a health 117 status and symptoms for each subservice in the assurance tree. This 118 module is intended for the following use cases: 120 o Assurance tree configuration: 122 * Subservices: configure a set of subservices to assure, by 123 specifying their types and parameters. 125 * Dependencies: configure the dependencies between the 126 subservices, along with their type. 128 o Assurance telemetry: export the health status of the subservices, 129 along with the observed symptoms. 131 The second YANG module, ietf-service-assurance-device, extends the 132 ietf-service-assurance module to add support for the subservice 133 DeviceHealthy. Additional subservice types might be added the same 134 way. 136 The third YANG module, example-service-assurance-device-acme, extends 137 the ietf-service-assurance-device module as an example to add support 138 for the subservice DeviceHealthy, with specifics for the fictional 139 ACME Corporation. Additional vendor-specific parameters might be 140 added the same way. 142 4. Base ietf-service-assurance YANG module 144 4.1. Tree View 146 The following tree diagram [RFC8340] provides an overview of the 147 ietf-service-assurance data model. 149 module: ietf-service-assurance 150 +--ro assurance-tree-version? yang:counter32 151 +--ro assurance-tree-last-change? yang:date-and-time 152 +--rw subservices 153 +--rw subservice* [type id] 154 +--rw type identityref 155 +--rw id string 156 +--ro last-change? yang:date-and-time 157 +--ro label? string 158 +--rw (parameter)? 159 | +--:(service-instance-parameter) 160 | +--rw service-instance-parameter 161 | +--rw service? string 162 | +--rw instance-name? string 163 +--ro health-status? uint8 164 +--ro symptoms* [start-date id] 165 | +--ro id string 166 | +--ro health-status? uint8 167 | +--ro label? string 168 | +--ro start-date yang:date-and-time 169 | +--ro stop-date? yang:date-and-time 170 +--rw dependency* [type id] 171 +--rw type -> /subservices/subservice/type 172 +--rw id -> /subservices/subservice[type=current()/../type]/id 173 +--rw dependency-type? identityref 175 4.2. Concepts 177 The ietf-service-assurance YANG model assumes an identified number of 178 subservices, to be assured independently. A subservice is a feature 179 or a subpart of the network system that a given service instance 180 might depend on. Example of subservices include: 182 o DeviceHealthy: whether a device is healthy, and if not, what are 183 the symptoms. Potential symptoms are "CPU overloaded", "Out of 184 RAM", or "Out of TCAM". 186 o ConnectivityHealthy: given two IP addresses owned by two devices, 187 what is the quality of the connection between them. Potential 188 symptoms are "No route available" or "ECMP Imbalance". 190 In both cases (the first example is a subservice representing a 191 subpart of the network system, while the second is a subservice 192 representing a feature of the network), each of these subservices 193 might depend on other subservices, for instance, the connectivity 194 might depend on a subservice representing the routing mechanism and 195 on a subservice representing ECMP. 197 The assurance of a given service instance can be obtained by 198 composing the assurance of the subservices that it depends on, via 199 the dependency relations. 201 In order to declare a subservice MUST provide: 203 o A type: identity inheriting of the base identity for subservice, 205 o An id: string uniquely identifying the subservice among those with 206 the same identity, 208 o Some parameters, which should be specified in an augmenting model, 209 as described in the next sections. 211 The type and id uniquely identify a given subservice. They are used 212 to indicate the dependencies. Dependencies have types as well. Two 213 types are specified in the model: 215 o Impacting: such a dependency indicates an impact on the health of 216 the dependent, 218 o Informational: such a dependency might explain why the dependent 219 has issues but does not impact its health. 221 Service instances MUST be modeled as a particular type of subservice 222 with two parameters, a type and an instance name. The type is the 223 name of the service defined in the network orchestrator, for instance 224 "point-to-point-l2vpn". The instance name is the name assigned to 225 the particular instance that we are assuring, for instance the name 226 of the customer using that instance. 228 By specifying service instances and their dependencies in terms of 229 subservices, one defines the whole assurance to apply for them. An 230 assurance agent supporting this model should then produce telemetry 231 in return with, for each subservice: a health-status indicating how 232 healthy the subservice is and when the subservice is not healthy, a 233 list of symptoms explaining why the subservice is not healthy. 235 4.3. YANG Module 237 file "ietf-service-assurance@2019-10-04.yang" 239 module ietf-service-assurance { 240 yang-version 1.1; 241 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance"; 242 prefix service-assurance; 244 import ietf-yang-types { 245 prefix yang; 246 } 248 organization 249 "IETF NETCONF (Network Configuration) Working Group"; 250 contact 251 "WG Web: 252 WG List: 253 Author: Benoit Claise 254 Author: Jean Quilbeuf "; 255 description 256 "This module defines objects for assuring network services based on 257 their decomposition into so-called subservices, according to the SAIN 258 (Service Assurance for Intent-based Networking) architecture. 260 The subservices hierarchically organised by dependencies constitute an 261 assurance tree. This module should be supported by an assurance agent, 262 able to interact with the devices in order to produce a health status 263 and symptoms for each subservice in the assurance tree. 265 This module is intended for the following use cases: 266 * Assurance tree configuration: 267 * subservices: configure a set of subservices to assure, by specifying 268 their types and parameters. 269 * dependencies: configure the dependencies between the subservices, 270 along with their type. 271 * Assurance telemetry: export the health status of the subservices, along 272 with the observed symptoms. 274 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 275 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 276 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 277 are to be interpreted as described in BCP 14 (RFC 2119) 278 (RFC 8174) when, and only when, they appear in all 279 capitals, as shown here. 281 Copyright (c) 2019 IETF Trust and the persons identified as 282 authors of the code. All rights reserved. 284 Redistribution and use in source and binary forms, with or 285 without modification, is permitted pursuant to, and subject 286 to the license terms contained in, the Simplified BSD License 287 set forth in Section 4.c of the IETF Trust's Legal Provisions 288 Relating to IETF Documents 289 (https://trustee.ietf.org/license-info). 291 This version of this YANG module is part of RFC XXXX; see the 292 RFC itself for full legal notices."; 294 revision 2019-10-02 { 295 description 296 "Initial revision."; 297 reference 298 "RFC xxxx: Title to be completed"; 299 } 301 identity subservice-idty { 302 description 303 "Root identity for all subservice types."; 304 } 306 identity service-instance-idty { 307 base subservice-idty; 308 description 309 "Identity representing a service instance."; 310 } 312 identity dependency-type { 313 description 314 "Base identity for representing dependency types."; 315 } 317 identity informational-dependency { 318 base dependency-type; 319 description 320 "Indicates that symptoms of the dependency might be of interest for the 321 dependent, but the status of the dependency should not have any 322 impact on the dependent."; 323 } 325 identity impacting-dependency { 326 base dependency-type; 327 description 328 "Indicates that the status of the dependency directly impacts the status 329 of the dependent."; 330 } 331 grouping symptom { 332 description 333 "Contains the list of symptoms for a specific subservice."; 334 leaf id { 335 type string; 336 description 337 "A unique identifier for the symptom."; 338 } 339 leaf health-status { 340 type uint8 { 341 range "0 .. 100"; 342 } 343 description 344 "The impact to the health score incurred by this symptom. The lower the 345 value, the more of an impact this symptom has. If a subservice health 346 score is not 100, there must be at least one symptom such that the 347 health-status of that symptom is equal to the health score of the 348 subservice. In other words, there must always be a symptom explaining 349 why the subservice health score is lower than 100."; 350 } 351 leaf label { 352 type string; 353 description 354 "Label of the symptom, i.e. text describing what the symptom is, to 355 be computer-consumable and be displayed on a human interface."; 356 } 357 leaf start-date { 358 type yang:date-and-time; 359 description 360 "Date and time at which the symptom was detected."; 361 } 362 leaf stop-date { 363 type yang:date-and-time; 364 description 365 "Date and time at which the symptom stopped being detected."; 366 } 367 } 369 grouping subservice-dependency { 370 description 371 "Represent a dependency to another subservice."; 372 leaf type { 373 type leafref { 374 path "/subservices/subservice/type"; 375 } 376 description 377 "The type of the subservice to refer to (e.g. DeviceHealthy)."; 378 } 379 leaf id { 380 type leafref { 381 path "/subservices/subservice[type=current()/../type]/id"; 382 } 383 description 384 "The identifier of the subservice to refer to."; 385 } 386 leaf dependency-type { 387 type identityref { 388 base dependency-type; 389 } 390 description 391 "Represents the type of dependency (i.e. informational, impacting)."; 392 } 393 // augment here if more info are needed (i.e. a percentage) depending on the dependency type. 394 } 396 leaf assurance-tree-version { 397 type yang:counter32; 398 config false; 399 description 400 "The assurance tree version, which increases by 1 for each new version."; 401 } 402 leaf assurance-tree-last-change { 403 type yang:date-and-time; 404 config false; 405 description 406 "Date and time at which the assurance tree last changed."; 407 } 408 container subservices { 409 description 410 "Root container for the subservices."; 411 list subservice { 412 key "type id"; 413 description 414 "List of subservice configured."; 415 leaf type { 416 type identityref { 417 base subservice-idty; 418 } 419 description 420 "Name of the subservice, e.g. DeviceHealthy."; 421 } 422 leaf id { 423 type string; 424 description 425 "Unique identifier of the subservice instance, for each type."; 426 } 427 leaf last-change { 428 type yang:date-and-time; 429 config false; 430 description 431 "Date and time at which the assurance tree for this subservice 432 instance last changed."; 433 } 434 leaf label { 435 type string; 436 config false; 437 description 438 "Label for displaying the subservice name in human readable form."; 439 } 440 choice parameter { 441 description 442 "Specify the required parameters per subservice type."; 443 container service-instance-parameter { 444 when "derived-from-or-self(../type, 'service-instance-idty')"; 445 description 446 "Specify the parameters of a service instance."; 447 leaf service { 448 type string; 449 description "Name of the service."; 450 } 451 leaf instance-name{ 452 type string; 453 description "Name of the instance for that service."; 454 } 455 } 456 // Other modules can augment their own cases into here 457 } 458 leaf health-status { 459 type uint8 { 460 range "0 .. 100"; 461 } 462 config false; 463 description 464 "Score value of the subservice health, also known as the subservice 465 status. A value of 100 means that subservice is healthy. A value of 0 means 466 that the subservice is broken. A value between 0 and 100 means that the 467 subservice is degraded."; 468 } 469 list symptoms { 470 //key id; 471 key "start-date id"; 472 config false; 473 description 474 "List of symptoms the subservice. While the start-date key is not 475 necessary per se, this would get the entries sorted by start-date 476 for easy consumption."; 477 uses symptom; 478 } 479 list dependency { 480 key "type id"; 481 description 482 "List of soft dependencies of the subservice."; 483 uses subservice-dependency; 484 } 485 } 486 } 487 } 489 491 5. Subservice Extension: ietf-service-assurance-device YANG module 493 5.1. Tree View 495 The following tree diagram [RFC8340] provides an overview of the 496 ietf-service-assurance-device data model. 498 module: ietf-service-assurance-device 499 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 500 +--rw device-idty 501 +--rw device? string 503 5.2. Complete Tree View 505 The following tree diagram [RFC8340] provides an overview of the 506 ietf-service-assurance and ietf-service-assurance-device data models. 508 module: ietf-service-assurance 509 +--ro assurance-tree-version? yang:counter32 510 +--ro assurance-tree-last-change? yang:date-and-time 511 +--rw subservices 512 +--rw subservice* [type id] 513 +--rw type identityref 514 +--rw id string 515 +--ro last-change? yang:date-and-time 516 +--ro label? string 517 +--rw (parameter)? 518 | +--:(service-instance-parameter) 519 | | +--rw service-instance-parameter 520 | | +--rw service? string 521 | | +--rw instance-name? string 522 | +--:(service-assurance-device:device-idty) 523 | +--rw service-assurance-device:device-idty 524 | +--rw service-assurance-device:device? string 525 +--ro health-status? uint8 526 +--ro symptoms* [start-date id] 527 | +--ro id string 528 | +--ro health-status? uint8 529 | +--ro label? string 530 | +--ro start-date yang:date-and-time 531 | +--ro stop-date? yang:date-and-time 532 +--rw dependency* [type id] 533 +--rw type -> /subservices/subservice/type 534 +--rw id -> /subservices/subservice[type=current()/../type]/id 535 +--rw dependency-type? identityref 537 5.3. Concepts 539 As the number of subservices will grow over time, the YANG module is 540 designed to be extensible. A new subservice type requires the 541 precise specifications of tis type and the parameters. Let us 542 illustrate the example of the new DeviceHealthy subservice type. As 543 the name implies, it monitors and reports the device health, along 544 with some symptoms in case of degradation. 546 For our DeviceHealthy subservice definitions, the new device-idty is 547 specified, as an inheritance from the base identity for subservices. 548 This indicates to the assurance agent that we are now assuring the 549 health of a device. 551 The typical parameter for the configuration of the DeviceHealthy 552 subservice is the name of the device that we want to assure. By 553 augmenting the parameter choice from ietf-service-assurance YANG 554 module for the case of the device-idty subservice type, this new 555 parameter is specified. 557 5.4. YANG Module 559 file "ietf-service-assurance-device@2019-10-04.yang" 561 module ietf-service-assurance-device { 562 yang-version 1.1; 563 namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; 564 prefix service-assurance-device; 566 import ietf-service-assurance { 567 prefix "service-assurance"; 568 } 570 organization 571 "IETF NETCONF (Network Configuration) Working Group"; 572 contact 573 "WG Web: 574 WG List: 575 Author: Benoit Claise 576 Author: Jean Quilbeuf "; 577 description 578 "This module extends the ietf-service-assurance module to add 579 support for the subservice DeviceHealthy. 581 Network Device is healthy. 583 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 584 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 585 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 586 are to be interpreted as described in BCP 14 (RFC 2119) 587 (RFC 8174) when, and only when, they appear in all 588 capitals, as shown here. 590 Copyright (c) 2019 IETF Trust and the persons identified as 591 authors of the code. All rights reserved. 593 Redistribution and use in source and binary forms, with or 594 without modification, is permitted pursuant to, and subject 595 to the license terms contained in, the Simplified BSD License 596 set forth in Section 4.c of the IETF Trust's Legal Provisions 597 Relating to IETF Documents 598 (https://trustee.ietf.org/license-info). 600 This version of this YANG module is part of RFC XXXX; see the 601 RFC itself for full legal notices."; 603 revision 2019-10-04 { 604 description 605 "Initial revision."; 606 reference 607 "RFC xxxx: Title to be completed"; 608 } 610 identity device-idty { 611 base service-assurance:subservice-idty; 612 description "Network Device is healthy."; 613 } 615 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter { 616 description 617 "Specify the required parameters for a new subservice type"; 618 container device-idty{ 619 when "derived-from-or-self(../service-assurance:type, 'device-idty')"; 620 description 621 "Specify the required parameters for the device-idty subservice type"; 623 leaf device { 624 type string; 625 description "The device to monitor."; 626 } 627 } 628 } 629 } 631 633 6. Vendor-specific Subservice Extension: example-service-assurance- 634 device-acme YANG module 636 6.1. Tree View 638 The following tree diagram [RFC8340] provides an overview of the 639 example-service-assurance-device-acme data model. 641 module: example-service-assurance-device-acme 642 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter: 643 +--rw acme-device-idty 644 +--rw device? string 645 +--rw acme-specific-parameter? string 647 6.2. Complete Tree View 649 The following tree diagram [RFC8340] provides an overview of the 650 ietf-service-assurance, ietf-service-assurance-device, and example- 651 service-assurance-device-acme data models. 653 module: ietf-service-assurance 654 +--ro assurance-tree-version? yang:counter32 655 +--ro assurance-tree-last-change? yang:date-and-time 656 +--rw subservices 657 +--rw subservice* [type id] 658 +--rw type identityref 659 +--rw id string 660 +--ro last-change? yang:date-and-time 661 +--ro label? string 662 +--rw (parameter)? 663 | +--:(service-instance-parameter) 664 | | +--rw service-instance-parameter 665 | | +--rw service? string 666 | | +--rw instance-name? string 667 | +--:(service-assurance-device:device-idty) 668 | | +--rw service-assurance-device:device-idty 669 | | +--rw service-assurance-device:device? string 670 | +--:(example-service-assurance-device-acme:acme-device-idty) 671 | +--rw example-service-assurance-device-acme:acme-device-idty 672 | +--rw example-service-assurance-device-acme:device? string 673 | +--rw example-service-assurance-device-acme:acme-specific-parameter? string 674 +--ro health-status? uint8 675 +--ro symptoms* [start-date id] 676 | +--ro id string 677 | +--ro health-status? uint8 678 | +--ro label? string 679 | +--ro start-date yang:date-and-time 680 | +--ro stop-date? yang:date-and-time 681 +--rw dependency* [type id] 682 +--rw type -> /subservices/subservice/type 683 +--rw id -> /subservices/subservice[type=current()/../type]/id 684 +--rw dependency-type? identityref 686 6.3. Concepts 688 Under some circumstances, vendor-specific subservice types might be 689 required. As an example of this vendor-specific implementation, this 690 section shows how to augment the ietf-service-assurance-device module 691 to add support for the subservice DeviceHealthy, specific to the ACME 692 Corporation. The new parameter is acme-specific-parameter. 694 6.4. YANG Module 696 file "module example-service-assurance-device- 697 acme@2019-10-04.yang" 699 module example-service-assurance-device-acme { 700 yang-version 1.1; 701 namespace "urn:example:example-service-assurance-device-acme"; 702 prefix example-service-assurance-device-acme; 704 import ietf-service-assurance { 705 prefix "service-assurance"; 706 } 708 import ietf-service-assurance-device { 709 prefix "service-assurance-device"; 710 } 712 organization 713 "IETF NETCONF (Network Configuration) Working Group"; 714 contact 715 "WG Web: 716 WG List: 717 Author: Benoit Claise 718 Author: Jean Quilbeuf "; 719 description 720 "This module extends the ietf-service-assurance-device module to add 721 support for the subservice DeviceHealthy, specific to the ACME Corporation. 723 ACME Network Device is healthy. 725 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 726 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 727 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 728 are to be interpreted as described in BCP 14 (RFC 2119) 729 (RFC 8174) when, and only when, they appear in all 730 capitals, as shown here. 732 Copyright (c) 2019 IETF Trust and the persons identified as 733 authors of the code. All rights reserved. 735 Redistribution and use in source and binary forms, with or 736 without modification, is permitted pursuant to, and subject 737 to the license terms contained in, the Simplified BSD License 738 set forth in Section 4.c of the IETF Trust's Legal Provisions 739 Relating to IETF Documents 740 (https://trustee.ietf.org/license-info). 742 This version of this YANG module is part of RFC XXXX; see the 743 RFC itself for full legal notices. "; 745 revision 2019-10-04 { 746 description 747 "Initial revision."; 748 reference 749 "RFC xxxx: Title to be completed"; 750 } 752 identity device-acme-idty { 753 base service-assurance-device:device-idty; 754 description "Network Device is healthy."; 755 } 757 augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter { 758 description 759 "Specify the required parameters for a new subservice type"; 760 container acme-device-idty{ 761 when "derived-from-or-self(../service-assurance:type, 'device-acme-idty')"; 762 description 763 "Specify the required parameters for the device-acme-idty subservice type"; 765 leaf device { 766 type string; 767 description "The device to monitor."; 768 } 770 leaf acme-specific-parameter { 771 type string; 772 description "The ACME Corporation sepcific parameter."; 773 } 774 } 775 } 776 } 778 780 7. Security Considerations 782 The YANG module specified in this document defines a schema for data 783 that is designed to be accessed via network management protocols such 784 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 785 is the secure transport layer, and the mandatory-to-implement secure 786 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 787 is HTTPS, and the mandatory-to-implement secure transport is TLS 788 [RFC8446]. 790 The Network Configuration Access Control Model (NACM) [RFC8341] 791 provides the means to restrict access for particular NETCONF or 792 RESTCONF users to a preconfigured subset of all available NETCONF or 793 RESTCONF protocol operations and content. 795 TO BE populated according to https://trac.ietf.org/trac/ops/wiki/ 796 yang-security-guidelines 798 8. IANA Considerations 800 8.1. The IETF XML Registry 802 This document registers two URIs in the IETF XML registry [RFC3688]. 803 Following the format in [RFC3688], the following registrations are 804 requested: 806 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance 807 Registrant Contact: The NETCONF WG of the IETF. 808 XML: N/A, the requested URI is an XML namespace. 810 URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device 811 Registrant Contact: The NETCONF WG of the IETF. 812 XML: N/A, the requested URI is an XML namespace. 814 8.2. The YANG Module Names Registry 816 This document registers two YANG modules in the YANG Module Names 817 registry [RFC7950]. Following the format in [RFC7950], the the 818 following registrations are requested: 820 name: ietf-service-assurance 821 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance 822 prefix: inc 823 reference: RFC XXXX 825 name: ietf-service-assurance-device 826 namespace: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device 827 prefix: inc 828 reference: RFC XXXX 830 9. Open Issues 832 -Complete the Security Considerations 834 10. References 836 10.1. Normative References 838 [draft-claise-opsawg-service-assurance-architecture] 839 Claise, B. and J. Quilbeuf, "draft-claise-opsawg-service- 840 assurance-architecture", 2019. 842 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 843 and A. Bierman, Ed., "Network Configuration Protocol 844 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 845 . 847 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 848 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 849 . 851 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 852 RFC 7950, DOI 10.17487/RFC7950, August 2016, 853 . 855 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 856 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 857 . 859 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 860 Access Control Model", STD 91, RFC 8341, 861 DOI 10.17487/RFC8341, March 2018, 862 . 864 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 865 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 866 . 868 10.2. Informative References 870 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 871 Requirement Levels", BCP 14, RFC 2119, 872 DOI 10.17487/RFC2119, March 1997, 873 . 875 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 876 DOI 10.17487/RFC3688, January 2004, 877 . 879 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 880 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 881 May 2017, . 883 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 884 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 885 . 887 Acknowledgements 889 The authors would like to thank Jan Lindlab for his help during the 890 design of these YANG modules. 892 Authors' Addresses 894 Benoit Claise 895 Cisco Systems, Inc. 896 De Kleetlaan 6a b1 897 1831 Diegem 898 Belgium 900 Email: bclaise@cisco.com 902 Jean Quilbeuf 903 Cisco Systems, Inc. 904 1, rue Camille Desmoulins 905 92782 Issy Les Moulineaux 906 France 908 Email: jquilbeu@cisco.com