OPSAWG                                                         B. Claise
Internet-Draft                                                    Huawei                                               J. Quilbeuf
Intended status: Standards Track                             J. Quilbeuf                                  Huawei
Expires: November 22, 2021                                   Independent January 3, 2022                                      P. Lucente
                                                                     NTT
                                                               P. Fasano
                                                               TIM S.p.A
                                                             T. Arumugam
                                                     Cisco Systems, Inc.
                                                            May 21,
                                                            July 2, 2021

                   YANG Modules for Service Assurance
              draft-ietf-opsawg-service-assurance-yang-00
              draft-ietf-opsawg-service-assurance-yang-01

Abstract

   This document proposes YANG modules for the Service Assurance for
   Intent-based Networking Architecture.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 22, 2021. January 3, 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  YANG Models Overview  . . . . . . . . . . . . . . . . . . . .   3
   4.  Base ietf-service-assurance YANG module . . . . . . . . . . .   4
     4.1.  Tree View . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  YANG Module . . . . . . . . . . . . . . . . . . . . . . .   6   7
   5.  Subservice Extension: ietf-service-assurance-device YANG
       module  . . . . . . . . . . . . . . . . . . . . . . . . . . .  13  14
     5.1.  Tree View . . . . . . . . . . . . . . . . . . . . . . . .  13  14
     5.2.  Complete Tree View  . . . . . . . . . . . . . . . . . . .  13  14
     5.3.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . .  14  15
     5.4.  YANG Module . . . . . . . . . . . . . . . . . . . . . . .  15  16
   6.  Subservice Extension: ietf-service-assurance-interface YANG
       module  . . . . . . . . . . . . . . . . . . . . . . . . . . .  16  18
     6.1.  Tree View . . . . . . . . . . . . . . . . . . . . . . . .  16  18
     6.2.  Complete Tree View  . . . . . . . . . . . . . . . . . . .  17  18
     6.3.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . .  18  19
     6.4.  YANG Module . . . . . . . . . . . . . . . . . . . . . . .  18  20
   7.  Vendor-specific Subservice Extension: example-service-
       assurance-device-acme YANG module . . . . . . . . . . . . . .  19  22
     7.1.  Tree View . . . . . . . . . . . . . . . . . . . . . . . .  19  22
     7.2.  Complete Tree View  . . . . . . . . . . . . . . . . . . .  20  22
     7.3.  Concepts  . . . . . . . . . . . . . . . . . . . . . . . .  21  23
     7.4.  YANG Module . . . . . . . . . . . . . . . . . . . . . . .  22  24
   8.  Security Considerations  Further Extensions: IP Connectivity and IS-IS subservices . .  26
     8.1.  IP Connectivity Tree View . . . . . . . . . . . . . . . .  26
     8.2.  IS-IS Tree View .  23
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . .  26
     8.3.  Global Tree View  .  24
     9.1.  The IETF XML Registry . . . . . . . . . . . . . . . . . .  24
     9.2.  The .  26
     8.4.  IP Connectivity YANG Module Names Registry . . . . . . . . . . . . .  25
   10. Open Issues . .  28
     8.5.  IS-IS YANG Module . . . . . . . . . . . . . . . . . . . .  30
   9.  Guidelines for Specific Subservice Extension  . . .  25
   11. References . . . . .  31
     9.1.  Module Name . . . . . . . . . . . . . . . . . . . .  25
     11.1.  Normative References . . .  32
     9.2.  Module Namespace  . . . . . . . . . . . . . . .  25
     11.2.  Informative References . . . . .  32
     9.3.  Module Prefix . . . . . . . . . . . .  26
   Appendix A.  Changes between revisions . . . . . . . . . .  32
     9.4.  Subservice Specific Identity  . . .  26
   Acknowledgements . . . . . . . . . . .  33
     9.5.  Parameters  . . . . . . . . . . . . .  27
   Authors' Addresses . . . . . . . . . .  33
   10. Security Considerations . . . . . . . . . . . . .  27

1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here. . . . . . .  33
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
     11.1.  The terms used in this document are defined in draft-claise-opsawg-
   service-assurance-architecture IETF draft.

2.  Introduction XML Registry  . . . . . . . . . . . . . . . . .  34
     11.2.  The "Service Assurance for Intent-based Networking Architecture"
   draft-claise-opsawg-service-assurance-architecture, specifies the
   framework and all of its components for service assurance.  This
   document complements the architecture by providing open interfaces
   between components.  More specifically, the goal is to provide YANG
   modules for the purpose of service assurance in a format that Module Names Registry . . . . . . . . . . . . .  34
   12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . .  35
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  35
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  35
     13.2.  Informative References . . . . . . . . . . . . . . . . .  36
   Appendix A.  Example of YANG instances  . . . . . . . . . . . . .  36
   Appendix B.  YANG Library for Service Assurance . . . . . . . . .  40
   Appendix C.  Changes between revisions  . . . . . . . . . . . . .  41
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  42
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  42

1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The terms used in this document are defined in
   [I-D.ietf-opsawg-service-assurance-architecture]

2.  Introduction

   The "Service Assurance for Intent-based Networking Architecture"
   draft-ietf-opsawg-service-assurance-architecture, specifies the
   architecture and all of its components for service assurance.  This
   document complements the architecture by providing open interfaces
   between components.  More specifically, the goal is to provide YANG
   modules for the purpose of service assurance in a format that is:

   o  machine readable  machine readable

   o  vendor independent

   o  augmentable

3.  YANG Models Overview

   The main YANG module, ietf-service-assurance, defines objects for
   assuring network services based on their decomposition into so-called
   subservices.  The subservices are hierarchically organised by
   dependencies.  The subservices, along with the dependencies,
   constitute an assurance graph.  This module should be supported by an
   agent, able to interact with the devices in order to produce a health
   status and symptoms for each subservice in the assurance graph.  This
   module is intended for the following use cases:

   o  Assurance graph configuration:

      *  Subservices: configure a set of subservices to assure, by
         specifying their types and parameters.

      *  Dependencies: configure the dependencies between the
         subservices, along with their type.

   o  Assurance telemetry: export the health status of the subservices,
      along with the observed symptoms.

   The second YANG module, ietf-service-assurance-device, extends the
   ietf-service-assurance module to add support for the subservice
   DeviceHealthy.  Additional subservice types might be added the same
   way.

   The third YANG module, ietf-service-assurance-device, is another
   example that extends the ietf-service-assurance-device module.  This
   extension adds support for the subservice InterfaceHealthy.

   The fourth YANG module, example-service-assurance-device-acme,
   extends the ietf-service-assurance-device module as an example to add
   support for the subservice DeviceHealthy, with specifics for the
   fictional ACME Corporation.  Additional vendor-specific parameters
   might be added the same way.

   Finally, the modules ietf-service-assurance-ip-connectivity and ietf-
   service-assurance-is-is are provided to completely model the example
   from the SAIN architecture draft
   [I-D.ietf-opsawg-service-assurance-architecture].

4.  Base ietf-service-assurance YANG module

4.1.  Tree View

   The following tree diagram [RFC8340] provides an overview of the
   ietf-service-assurance data model.

module: ietf-service-assurance
  +--ro assurance-graph-version        yang:counter32
  +--ro assurance-graph-last-change    yang:date-and-time
  +--rw subservices
     +--rw subservice* [type id]
        +--rw type                                identityref
        +--rw id                                  string
        +--ro last-change?                        yang:date-and-time
        +--ro label?                              string
        +--rw under-maintenance?                  boolean
        +--rw maintenance-contact                 string
        +--rw (parameter)?
        |  +--:(service-instance-parameter)
        |     +--rw service-instance-parameter
        |        +--rw service          string
        |        +--rw instance-name    string
        +--ro health-score?                       uint8
        +--ro symptoms-history-start?             yang:date-and-time
        +--rw symptoms
        |  +--ro symptom* [start-date-time id]
        |     +--ro id                     string
        |     +--ro health-score-weight?   uint8
        |     +--ro description?           string
        |     +--ro start-date-time        yang:date-and-time
        |     +--ro stop-date-time?        yang:date-and-time
        +--rw dependencies
           +--rw dependency* [type id]
              +--rw type               -> /subservices/subservice/type
              +--rw id                 -> /subservices/subservice[type=current()/../type]/id
              +--rw dependency-type?   identityref

4.2.  Concepts

   The ietf-service-assurance YANG model assumes an identified number of
   subservices, to be assured independently.  A subservice is a feature
   or a subpart of the network system that a given service instance
   might depend on.  Example of subservices include:

   o  DeviceHealthy: whether a device is healthy, and if not, what are
      the symptoms.  Potential symptoms are "CPU overloaded", "Out of
      RAM", or "Out of TCAM".

   o  ConnectivityHealthy: given two IP addresses owned by two devices,
      what is the quality of the connection between them.  Potential
      symptoms are "No route available" or "ECMP Imbalance".

   The first example is a subservice representing a subpart of the
   network system, while the second is a subservice representing a
   feature of the network, In both cases, these subservices might depend
   on other subservices, for instance, the connectivity might depend on
   a subservice representing the routing mechanism and on a subservice
   representing ECMP.

   The status of each subservice contains a list of symptoms.  Each
   symptom is specified by a unique id and contains a health-score-
   weight (the impact to the health score incurred by this symptom), a
   label (text describing what the symptom is), and dates and times at
   which the symptom was detected and stopped being detected.  While the
   unique id is sufficient as an unique key list, the start-date-time
   second key help sorting and retrieving relevant symptoms.

   The assurance of a given service instance can be obtained by
   composing the assurance of the subservices that it depends on, via
   the dependency relations.

   A subservice declaration MUST provide:

   o  A type: identity inheriting of the base identity for subservice,

   o  vendor independent  An id: string uniquely identifying the subservice among those with
      the same identity,

   o  augmentable

3.  YANG Models Overview  One or more parameters, which should be specified in an augmenting
      model, as described in the next sections.

   The type and id uniquely identify a given subservice.  They are used
   to indicate the dependencies.  Dependencies have types as well.  Two
   types are specified in the model:

   o  Impacting: such a dependency indicates an impact on the health of
      the dependent,

   o  Informational: such a dependency might explain why the dependent
      has issues but does not impact its health.

   To illustrate the difference between "impacting" and "informational",
   consider the subservice InterfaceHealthy, representing a network
   interface.  If the device to which the network interface belongs goes
   down, the network interface will transition to a down state as well.
   Therefore, the dependency of InterfaceHealthy towards DeviceHealthy
   is "impacting".  On the other hand, as a the dependency towards the
   ECMPLoad subservice, which checks that the load between ECMP remains
   ce remains stable throughout time, is only "informational".  Indeed,
   services might be perfectly healthy even if the load distribution
   between ECMP changed.  However, such an instability might be a
   relevant symptom for diagnosing the root cause of a problem.

   Service instances MUST be modeled as a particular type of subservice
   with two parameters, a type and an instance name.  The type is the
   name of the service defined in the network orchestrator, for instance
   "point-to-point-l2vpn".  The main instance name is the name assigned to
   the particular instance that we are assuring, for instance the name
   of the customer using that instance.

   The "under-maintenance" and "maintenance-contact" flags inhibit the
   emission of symptoms for that subservice and subservices that depend
   on them.  See Section 3.7 of
   [I-D.ietf-opsawg-service-assurance-architecture] for a more detailed
   discussion.

   By specifying service instances and their dependencies in terms of
   subservices, one defines the whole assurance to apply for them.  An
   assurance agent supporting this model should then produce telemetry
   in return with, for each subservice: a health-status indicating how
   healthy the subservice is and when the subservice is not healthy, a
   list of symptoms explaining why the subservice is not healthy.

4.3.  YANG module, ietf-service-assurance, Module

   <CODE BEGINS> file "ietf-service-assurance@2021-06-28.yang"

module ietf-service-assurance {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance";
  prefix service-assurance;

  import ietf-yang-types {
    prefix yang;
  }

  organization
    "IETF NETCONF (Network Configuration) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/netconf/>
     WG List:  <mailto:netconf@ietf.org>
     Author:   Benoit Claise  <mailto:benoit.claise@huawei.com>
     Author:   Jean Quilbeuf   <mailto:jean.quilbeu@huawei.com>";
  description
    "This module defines objects for assuring network services based on
     their decomposition into so-called
   subservices. subservices, according to the SAIN
     (Service Assurance for Intent-based Networking) architecture.

     The subservices are hierarchically organised by
   dependencies.  The subservices, along with the dependencies, dependencies constitute an
     assurance graph. This module should be supported by an assurance agent,
     able to interact with the devices in order to produce a health status
     and symptoms for each subservice in the assurance graph.

     This module is intended for the following use cases:

   o
     * Assurance graph configuration:
      *  Subservices: subservices: configure a set of subservices to assure, by specifying
        their types and parameters.
      *  Dependencies: dependencies: configure the dependencies between the subservices,
         along with their type.

   o
     * Assurance telemetry: export the health status of the subservices, along
      with the observed symptoms.

     The second YANG module, ietf-service-assurance-device, extends the
   ietf-service-assurance module key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
     'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
     'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
     are to add support for the subservice
   DeviceHealthy.  Additional subservice types might be added the same
   way.

   The third YANG module, example-service-assurance-device-acme, extends interpreted as described in BCP 14 (RFC 2119)
     (RFC 8174) when, and only when, they appear in all
     capitals, as shown here.

     Copyright (c)2021 IETF Trust and the ietf-service-assurance-device module persons identified as an example to add support
   for
     authors of the subservice DeviceHealthy, code.  All rights reserved.

     Redistribution and use in source and binary forms, with specifics for or
     without modification, is permitted pursuant to, and subject
     to the fictional
   ACME Corporation.  Additional vendor-specific parameters might be
   added license terms contained in, the same way.

4.  Base ietf-service-assurance Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module

4.1.  Tree View

   The following tree diagram [RFC8340] provides an overview is part of RFC XXXX; see the
   ietf-service-assurance data model.

module: ietf-service-assurance
  +--ro assurance-graph-version        yang:counter32
  +--ro assurance-graph-last-change    yang:date-and-time
  +--rw subservices
     +--rw subservice* [type id]
        +--rw type                                identityref
        +--rw id                                  string
        +--ro last-change?                        yang:date-and-time
        +--ro label?                              string
        +--rw under-maintenance?                  boolean
        +--rw maintenance-contact                 string
        +--rw (parameter)?
        |  +--:(service-instance-parameter)
        |     +--rw service-instance-parameter
        |        +--rw service?         string
        |        +--rw instance-name?   string
        +--ro health-score?                       uint8
        +--ro symptoms-history-start?             yang:date-and-time
        +--rw symptoms
        |  +--ro symptom* [start-date-time id]
        |     +--ro id                     string
        |     +--ro health-score-weight?   uint8
        |     +--ro description?           string
        |     +--ro start-date-time        yang:date-and-time
        |     +--ro stop-date-time?        yang:date-and-time
        +--rw dependencies
           +--rw dependency* [type id]
              +--rw
     RFC itself for full legal notices.
     TO DO:
     - Better type               -> /subservices/subservice/type
              +--rw id                 -> /subservices/subservice[type=current()/../type]/id
              +--rw dependency-type?   identityref

4.2.  Concepts

   The ietf-service-assurance (IETF or OC) for device-id, interface-id, etc.
     - Have a YANG model assumes an identified number of
   subservices, module for IETF and one for OC?";

  revision 2021-06-28 {
    description
      "Made service-instance parameters mandatory.";
    reference
      "RFC xxxx: Title to be assured independently.  A completed";
  }
  revision 2020-01-13 {
    description
      "Added the maintenance window concept.";
    reference
      "RFC xxxx: Title to be completed";

  }
  revision 2019-11-16 {
    description
      "Initial revision.";
    reference
      "RFC xxxx: Title to be completed";
  }

  identity subservice-idty {
    description
      "Root identity for all subservice is a feature
   or types.";
  }

  identity service-instance-idty {
    base subservice-idty;
    description
      "Identity representing a subpart service instance.";
  }

  identity dependency-type {
    description
      "Base identity for representing dependency types.";
  }

  identity informational-dependency {
    base dependency-type;
    description
      "Indicates that symptoms of the network system that a given service instance dependency might depend on.  Example be of subservices include:

   o  DeviceHealthy: whether a device is healthy, and if not, what are interest for the symptoms.  Potential symptoms are "CPU overloaded", "Out of
      RAM", or "Out of TCAM".

   o  ConnectivityHealthy: given two IP addresses owned by two devices,
      what is
       dependent, but the quality status of the connection between them.  Potential
      symptoms are "No route available" or "ECMP Imbalance".

   The first example is a subservice representing a subpart of dependency should not have any
       impact on the
   network system, while dependent.";
  }

  identity impacting-dependency {
    base dependency-type;
    description
      "Indicates that the second is a subservice representing a
   feature status of the network, In both cases, these subservices might depend
   on other subservices, for instance, dependency directly impacts the connectivity might depend on
   a subservice representing status
       of the routing mechanism and on a subservice
   representing ECMP.

   The dependent.";
  }

  grouping symptom {
    description
      "Contains the list of symptoms are listed for each subservice.  Each symptom is
   specified by a unique specific subservice.";
    leaf id and contains a {
      type string;
      description
        "A unique identifier for the symptom.";
    }
    leaf health-score-weight (the
   impact {
      type uint8 {
        range "0 .. 100";
      }
      description
        "The weight to the health score incurred by this symptom), a label (text
   describing what the symptom is), and dates and times at which the
   symptom was detected and stopped being detected.  While symptom. The higher the unique id
   is sufficient as an unique key list,
         value, the start-date-time second key
   help sorting and retrieving relevant symptoms.

   The assurance more of an impact this symptom has. If a given service instance can subservice health
         score is not 100, there must be obtained by
   composing the assurance of the subservices that it depends on, via
   the dependency relations.

   In order to declare at least one symptom with a subservice MUST provide:

   o  A type: identity inheriting health
         score weight larger than 0.";
    }
    leaf description {
      type string;
      description
        "Description of the base identity for subservice,

   o  An id: string uniquely identifying the subservice among those with symptom, i.e. text describing what the same identity,

   o  Some parameters, which should symptom is, to
         be specified in an augmenting model,
      as described in the next sections.

   The type computer-consumable and id uniquely identify a given subservice.  They are used
   to indicate the dependencies.  Dependencies have types as well.  Two
   types are specified in the model:

   o  Impacting: such a dependency indicates an impact be displayed on the health of
      the dependent,

   o  Informational: such a dependency might explain why the dependent
      has issues but does not impact its health.

   To illustrate human interface. ";
    }
    leaf start-date-time {
      type yang:date-and-time;
      description
        "Date and time at which the difference between "impacting" symptom was detected.";
    }
    leaf stop-date-time {
      type yang:date-and-time;
      description
        "Date and "informational",
   consider time at which the subservice InterfaceHealthy, representing symptom stopped being detected.";
    }
  }

  grouping subservice-dependency {
    description
      "Represent a network
   interface.  If the device dependency to which another subservice.";
    leaf type {
      type leafref {
        path "/subservices/subservice/type";
      }
      description
        "The type of the network interface belongs goes
   down, subservice to refer to (e.g. DeviceHealthy).";
    }
    leaf id {
      type leafref {
        path "/subservices/subservice[type=current()/../type]/id";
      }
      description
        "The identifier of the network interface will transition subservice to a down state as well.
   Therefore, refer to.";
    }
    leaf dependency-type {
      type identityref {
        base dependency-type;
      }
      description
        "Represents the dependency type of InterfaceHealthy towards DeviceHealthy
   is "impacting".  On the other hand, as dependency (i.e. informational, impacting).";
    }
    // augment here if more info are needed (i.e. a percentage) depending on the dependency towards type.
  }

  leaf assurance-graph-version {
    type yang:counter32;
    mandatory true;
    config false;
    description
      "The assurance graph version, which increases by 1 for each new version, after the
   ECMPLoad subservice, changes
       (dependencies and/or maintenance windows parameters) are applied to the subservice(s).";
  }
  leaf assurance-graph-last-change {
    type yang:date-and-time;
    mandatory true;
    config false;
    description
      "Date and time at which checks that the load between ECMP remains
   ce remains stable throughout time, is only "informational".  Indeed,
   services might be perfectly healthy even if assurance graph last changed after the load distribution
   between ECMP changed.  However, such an instability might changes (dependencies
       and/or maintenance windows parameters) are applied to the subservice(s). These date and time
       must be a
   relevant symptom more recent or equal compared to the more recent value of any changed subservices
       last-change";
  }
  container subservices {
    description
      "Root container for diagnosing the root cause subservices.";
    list subservice {
      key "type id";
      description
        "List of a problem.

   Service instances MUST be modeled as a particular subservice configured.";
      leaf type {
        type identityref {
          base subservice-idty;
        }
        description
          "Name of the subservice, e.g. DeviceHealthy.";
      }
      leaf id {
        type string;
        description
          "Unique identifier of the subservice
   with two parameters, a instance, for each type.";
      }
      leaf last-change {
        type yang:date-and-time;
        config false;
        description
          "Date and an time at which the assurance graph for this subservice
           instance name.  The last changed, i.e. dependencies and/or maintenance windows parameters.";
      }
      leaf label {
        type is the
   name string;
        config false;
        description
          "Label of the service defined in subservice, i.e. text describing what the network orchestrator, for instance
   "point-to-point-l2vpn".  The instance name subservice is the name assigned to
   the
           be displayed on a human interface.";
      }
      leaf under-maintenance {
        type boolean;
        default "false";
        description
          "An optional flag indicating whether this particular instance that we are assuring, for instance subservice is under
           maintenance. Under this circumstance, the name subservice symptoms and the
           symptoms of its dependencies in the customer using that instance. assurance graph should not be taken
           into account. Instead, the subservice should send a 'Under Maintenance'
           single symptom.

           The "under-maintenance" and "maintenance-contact" flags inhibit operator changing the under-maintenance value must set the
           maintenance-contact variable.

           When the
   emission of symptoms for that subservice is not under maintenance any longer, the
           under-maintenance flag must return to its default value and subservices that depend
   on them.  See Section 3.7
           the under-maintenance-owner variable deleted.";
      }
      leaf maintenance-contact {
        when "../under-maintenance = 'true'";
        type string;
        mandatory true;
        description
          "A string used to model an administratively assigned name of
   [draft-claise-opsawg-service-assurance-architecture] for a the
           resource that changed the under-maintenance value to 'true.

           It is suggested that this name contain one or more
   detailed discussion.

   By specifying service instances and their dependencies in terms of
   subservices, one defines the whole assurance to apply for them.  An
   assurance following:
           IP address, management station name, network manager's name, location,
           or phone number. In some cases the agent supporting itself will be the owner of
           an entry. In these cases, this model should then produce telemetry
   in return with, for each subservice: string shall be set to a health-status indicating how
   healthy string
           starting with 'monitor'.";
      }
      choice parameter {
        description
          "Specify the required parameters per subservice is and type.";
        container service-instance-parameter {
          when "derived-from-or-self(../type, 'service-assurance:service-instance-idty')";
          description
            "Specify the subservice is not healthy, parameters of a
   list service instance.";
          leaf service {
            type string;
            mandatory true;
            description
              "Name of symptoms explaining why the subservice is not healthy.

4.3.  YANG Module

   <CODE BEGINS> file "ietf-service-assurance@2020-01-13.yang"

module ietf-service-assurance {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance";
  prefix service-assurance;

  import ietf-yang-types {
    prefix yang; service.";
          }

  organization
    "IETF NETCONF (Network Configuration) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/netconf/>
     WG List:  <mailto:netconf@ietf.org>
     Author:   Benoit Claise  <mailto:bclaise@cisco.com>
     Author:   Jean Quilbeuf   <mailto:jquilbeu@cisco.com>";
          leaf instance-name {
            type string;
            mandatory true;
            description
    "This module defines objects
              "Name of the instance for assuring network services based on that service.";
          }
        }
        // Other modules can augment their decomposition own cases into so-called subservices, according to the SAIN
    (Service Assurance for Intent-based Networking) architecture.

    The subservices hierarchically organised by dependencies constitute an
    assurance graph. This module should be supported by an assurance agent,
    able to interact with here
      }
      leaf health-score {
        type uint8 {
          range "0 .. 100";
        }
        config false;
        description
          "Score value of the devices in order to produce a health status
    and symptoms for each subservice in the assurance graph.

    This module health. A value of 100 means that
           subservice is intended for the following use cases:
    * Assurance graph configuration:
      * subservices: configure a set healthy. A value of subservices to assure, by specifying
        their types and parameters.
      * dependencies: configure 0 means that the dependencies subservice is
           broken. A value between 0 and 100 means that the subservices,
         along with their type.
    * Assurance telemetry: export the health status of subservice is
           degraded.";
      }
      leaf symptoms-history-start {
        type yang:date-and-time;
        config false;
        description
          "Date and time at which the subservices, along
      with symptoms history starts for this
           subservice instance, either because the observed symptoms.

    The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
    'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
    'NOT RECOMMENDED', 'MAY', subservice instance
           started at that date and 'OPTIONAL' in this document
    are time or because the symptoms before that
           were removed due to be interpreted as described in BCP 14 (RFC 2119)
    (RFC 8174) when, and only when, they appear in all
    capitals, as shown here.

    Copyright (c)2020 IETF Trust and a garbage collection process.";
      }
      container symptoms {
        description
          "Symptoms for the persons identified as
    authors subservice.";
        list symptom {
          key "start-date-time id";
          config false;
          description
            "List of symptoms the code.  All rights reserved.

    Redistribution and use in source and binary forms, with or
    without modification, subservice. While the start-date-time key is permitted pursuant to, and subject
    to not
             necessary per se, this would get the entries sorted by start-date-time
             for easy consumption.";
          uses symptom;
        }
      }
      container dependencies {
        description
          "configure the license terms contained in, dependencies between the Simplified BSD License
    set forth in Section 4.c subservices, along with their types.";
        list dependency {
          key "type id";
          description
            "List of the IETF Trust's Legal Provisions
    Relating to IETF Documents
    (https://trustee.ietf.org/license-info).

    This version soft dependencies of this the subservice.";
          uses subservice-dependency;
        }
      }
    }
  }
}

   <CODE ENDS>

5.  Subservice Extension: ietf-service-assurance-device YANG module is part

5.1.  Tree View

   The following tree diagram [RFC8340] provides an overview of RFC XXXX; see the
    RFC itself for full legal notices.

    TO DO:
    - Better type (IETF or OC) for device-id, interface-id, etc.
    - Have a YANG module for IETF
   ietf-service-assurance-device data model.

module: ietf-service-assurance-device

  augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter:
    +--rw parameters
       +--rw device    string

5.2.  Complete Tree View

   The following tree diagram [RFC8340] provides an overview of the
   ietf-service-assurance and one for OC?";

  revision 2020-01-13 {
    description
      "Added ietf-service-assurance-device data models.

module: ietf-service-assurance
  +--ro assurance-graph-version        yang:counter32
  +--ro assurance-graph-last-change    yang:date-and-time
  +--rw subservices
     +--rw subservice* [type id]
        +--rw type                                         identityref
        +--rw id                                           string
        +--ro last-change?                                 yang:date-and-time
        +--ro label?                                       string
        +--rw under-maintenance?                           boolean
        +--rw maintenance-contact                          string
        +--rw (parameter)?
        |  +--:(service-instance-parameter)
        |  |  +--rw service-instance-parameter
        |  |     +--rw service          string
        |  |     +--rw instance-name    string
        |  +--:(service-assurance-device:parameters)
        |     +--rw service-assurance-device:parameters
        |        +--rw service-assurance-device:device    string
        +--ro health-score?                                uint8
        +--ro symptoms-history-start?                      yang:date-and-time
        +--rw symptoms
        |  +--ro symptom* [start-date-time id]
        |     +--ro id                     string
        |     +--ro health-score-weight?   uint8
        |     +--ro description?           string
        |     +--ro start-date-time        yang:date-and-time
        |     +--ro stop-date-time?        yang:date-and-time
        +--rw dependencies
           +--rw dependency* [type id]
              +--rw type               -> /subservices/subservice/type
              +--rw id                 -> /subservices/subservice[type=current()/../type]/id
              +--rw dependency-type?   identityref

5.3.  Concepts

   As the number of subservices will grow over time, the maintenance window concept.";
    reference
      "RFC xxxx: Title to be completed";
  }

  revision 2019-11-16 {
    description
      "Initial revision.";
    reference
      "RFC xxxx: Title YANG module is
   designed to be completed";
  }

  identity subservice-idty {
    description
      "Root identity for all extensible.  A new subservice types.";
  }

  identity service-instance-idty {
    base subservice-idty;
    description
      "Identity representing a service instance.";
  }

  identity dependency-type {
    description
      "Base identity for representing dependency types.";
  }

  identity informational-dependency {
    base dependency-type;
    description
      "Indicates that symptoms type requires the
   precise specifications of its type and expected parameters.  Let us
   illustrate the dependency might be example of interest for the
       dependent, but new DeviceHealthy subservice type.  As
   the status of name implies, it monitors and reports the dependency should not have any
       impact on device health, along
   with some symptoms in case of degradation.

   For our DeviceHealthy subservice definition, the dependent.";
  } new identity impacting-dependency { device-
   idty is specified, as an inheritance from the base dependency-type;
    description
      "Indicates identity for
   subservices.  This indicates to the assurance agent that we are now
   assuring the status health of a device.

   The typical parameter for the dependency directly impacts the status configuration of the dependent.";
  }
  grouping symptom {
    description
      "Contains DeviceHealthy
   subservice is the list name of symptoms for a specific subservice.";
    leaf id {
      type string;
      description
        "A unique identifier for the symptom.";
    }
    leaf health-score-weight {
      type uint8 {
        range "0 .. 100";
      }
      description
        "The weight device that we want to assure.  By
   augmenting the health score incurred by this symptom. The higher the
         value, parameter choice from ietf-service-assurance YANG
   module for the more case of an impact this symptom has. If a the device-idty subservice health
         score type, this new
   parameter is not 100, there must be at least one symptom with a health
         score weight larger than 0.";
    }
    leaf description specified.

5.4.  YANG Module

   <CODE BEGINS> file "ietf-service-assurance-device@2021-06-28.yang"

module ietf-service-assurance-device {
      type string;
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device";
  prefix service-assurance-device;

  import ietf-service-assurance {
    prefix service-assurance;
  }

  organization
    "IETF NETCONF (Network Configuration) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/netconf/>
     WG List:  <mailto:netconf@ietf.org>
     Author:   Benoit Claise  <mailto:benoit.claise@huawei.com>
     Author:   Jean Quilbeuf   <mailto:jean.quilbeuf@huawei.com>";
  description
        "Description of the symptom, i.e. text describing what
    "This module extends the symptom is, ietf-service-assurance module to
         be computer-consumable add
     support for the subservice DeviceHealthy.

     Checks whether a network device is healthy.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
     'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
     'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
     are to be displayed on a human interface. ";
    }
    leaf start-date-time {
      type yang:date-and-time;
      description
        "Date interpreted as described in BCP 14 (RFC 2119)
     (RFC 8174) when, and time at which the symptom was detected.";
    }
    leaf stop-date-time {
      type yang:date-and-time;
      description
        "Date only when, they appear in all
     capitals, as shown here.

     Copyright (c) 2021 IETF Trust and time at which the symptom stopped being detected.";
    }
  }

  grouping subservice-dependency {
    description
      "Represent a dependency to another subservice.";
    leaf type {
      type leafref {
        path "/subservices/subservice/type";
      }
      description
        "The type persons identified as
     authors of the subservice to refer code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to (e.g. DeviceHealthy).";
    }
    leaf id {
      type leafref {
        path "/subservices/subservice[type=current()/../type]/id";
      }
      description
        "The identifier the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the subservice IETF Trust's Legal Provisions
     Relating to refer to.";
    }
    leaf dependency-type {
      type identityref {
        base dependency-type;
      }
      description
        "Represents the type IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of dependency (i.e. informational, impacting).";
    }
    // augment here if more info are needed (i.e. a percentage) depending on this YANG module is part of RFC XXXX; see the dependency type.
  }

  leaf assurance-graph-version
     RFC itself for full legal notices.  ";

  revision 2021-06-28 {
    type yang:counter32;
    mandatory true;
    config false;
    description
      "The assurance graph version, which increases by 1 for each new version, after
      "Renamed the changes
       (dependencies and/or maintenance windows parameters) are applied container for parameters.";
    reference
      "RFC xxxx: Title to the subservice(s)."; be completed";
  }
  leaf assurance-graph-last-change
  revision 2020-01-13 {
    type yang:date-and-time;
    mandatory true;
    config false;
    description
      "Date and time at which the assurance graph last changed after
      "Added the changes (dependencies
       and/or maintenance windows parameters) are applied window concept.";
    reference
      "RFC xxxx: Title to the subservice(s). These date and time
       must be more recent or equal compared to the more recent value of any changed subservices
       last-change"; completed";
  }
  container subservices {
    description
      "Root container for the subservices.";
    list subservice {
      key "type id";
      description
        "List of subservice configured.";
      leaf type {
        type identityref
  revision 2019-11-16 {
          base subservice-idty;
        }
    description
          "Name of the subservice, e.g. DeviceHealthy.";
      "Initial revision.";
    reference
      "RFC xxxx: Title to be completed";
  }
      leaf id

  identity device-idty {
        type string;
    base service-assurance:subservice-idty;
    description
          "Unique identifier of the subservice instance, for each type.";
      "Network Device is healthy.";
  }
      leaf last-change

  augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" {
        type yang:date-and-time;
        config false;
    description
          "Date and time at which
      "Specify the assurance graph required parameters for this a new subservice
           instance last changed, i.e. dependencies and/or maintenance windows parameters.";
      }
      leaf label type";
    container parameters {
        type string;
        config false;
      when "derived-from-or-self(../service-assurance:type, 'device-idty')";
      description
          "Label of
        "Specify the subservice, i.e. text describing what required parameters for the device-idty subservice is to
           be displayed on a human interface.";
      } type";
      leaf under-maintenance device {
        type boolean;
        default false; string;
        mandatory true;
        description
          "An optional flag indicating whether this particular subservice is under
          maintenance. Under this circumstance,
          "The device to monitor.";
      }
    }
  }
}

   <CODE ENDS>

6.  Subservice Extension: ietf-service-assurance-interface YANG module

6.1.  Tree View

   The following tree diagram [RFC8340] provides an overview of the subservice symptoms and
   ietf-service-assurance-interface data model.

module: ietf-service-assurance-interface

  augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter:
    +--rw parameters
       +--rw device       string
       +--rw interface    string

6.2.  Complete Tree View

   The following tree diagram [RFC8340] provides an overview of the
   ietf-service-assurance, ietf-service-assurance-device, and ietf-
   service-assurance-interface data models.

module: ietf-service-assurance
  +--ro assurance-graph-version        yang:counter32
  +--ro assurance-graph-last-change    yang:date-and-time
  +--rw subservices
     +--rw subservice* [type id]
        +--rw type                                            identityref
        +--rw id                                              string
        +--ro last-change?                                    yang:date-and-time
        +--ro label?                                          string
        +--rw under-maintenance?                              boolean
        +--rw maintenance-contact                             string
        +--rw (parameter)?
        |  +--:(service-instance-parameter)
        |  |  +--rw service-instance-parameter
        |  |     +--rw service          string
        |  |     +--rw instance-name    string
        |  +--:(service-assurance-interface:parameters)
        |  |  +--rw service-assurance-interface:parameters
        |  |     +--rw service-assurance-interface:device       string
        |  |     +--rw service-assurance-interface:interface    string
        |  +--:(service-assurance-device:parameters)
        |     +--rw service-assurance-device:parameters
        |        +--rw service-assurance-device:device    string
        +--ro health-score?                                   uint8
        +--ro symptoms-history-start?                         yang:date-and-time
        +--rw symptoms of its
        |  +--ro symptom* [start-date-time id]
        |     +--ro id                     string
        |     +--ro health-score-weight?   uint8
        |     +--ro description?           string
        |     +--ro start-date-time        yang:date-and-time
        |     +--ro stop-date-time?        yang:date-and-time
        +--rw dependencies in the assurance graph should not be taken
          into account. Instead, the
           +--rw dependency* [type id]
              +--rw type               -> /subservices/subservice/type
              +--rw id                 -> /subservices/subservice[type=current()/../type]/id
              +--rw dependency-type?   identityref

6.3.  Concepts

   For our InterfaceHealthy subservice should send a 'Under Maintenance'
          single symptom.

          The operator changing the under-maintenance value must set the
          maintenance-contact variable.

          When definition, the subservice new interface-
   idty is not under maintenance any longer, the
          under-maintenance flag must return to its default value and
          the under-maintenance-owner variable deleted.";
      }
      leaf maintenance-contact {
        when "../under-maintenance = 'true'";
        type string;
        mandatory true;
        description
          "A string used to model specified, as an administratively assigned name of the
          resource that changed inheritance from the under-maintenance value base identity for
   subservices.  This indicates to 'true.

          It is suggested that this name contain one or more of the following:
          IP address, management station name, network manager's name, location,
          or phone number. In some cases the assurance agent itself will be that we are now
   assuring the owner health of an entry. In these cases, this string shall be set to a string
          starting with 'monitor'.";

      }
      choice parameter {
        description
          "Specify the required interface.

   The typical parameters per for the configuration of the InterfaceHealthy
   subservice type.";
        container service-instance-parameter {
          when "derived-from-or-self(../type, 'service-assurance:service-instance-idty')";
          description
            "Specify are the parameters name of the device and, on that specific device, a service instance.";
          leaf service {
            type string;
            description "Name of
   specific interface.  By augmenting the service.";
          }
          leaf instance-name{
            type string;
            description "Name parameter choice from ietf-
   service-assurance YANG module for the case of the instance for that service.";
          }
        }
        // Other modules can augment their own cases into here
      }
      leaf health-score interface-idty
   subservice type, those two new parameter are specified.

6.4.  YANG Module

   <CODE BEGINS> file "ietf-service-assurance-interface@2021-06-28.yang"

module ietf-service-assurance-interface {
        type uint8
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface";
  prefix service-assurance-interface;

  import ietf-service-assurance {
          range "0 .. 100";
    prefix service-assurance;
  }
        config false;

  organization
    "IETF OPSAWG Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>
     Author:   Benoit Claise  <mailto:benoit.claise@huawei.com>
     Author:   Jean Quilbeuf   <mailto:jean.quilbeuf@huawei.com>";
  description
           "Score value of
    "This module extends the ietf-service-assurance module to add
     support for the subservice health. A value of 100 means that
           subservice InterfaceHealthy.

     Checks whether an interface is healthy. A value

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
     'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
     'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
     are to be interpreted as described in BCP 14 (RFC 2119)
     (RFC 8174) when, and only when, they appear in all
     capitals, as shown here.

     Copyright (c) 2021 IETF Trust and the persons identified as
     authors of 0 means that the subservice code.  All rights reserved.
     Redistribution and use in source and binary forms, with or
     without modification, is
           broken. A value between 0 permitted pursuant to, and 100 means that subject
     to the subservice license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is
           degraded."; part of RFC XXXX; see the
     RFC itself for full legal notices.  ";

  revision 2021-06-28 {
    description
      "Regroup parameters in a container.";
    reference
      "RFC xxxx: Title to be completed";
  }
       leaf symptoms-history-start
  revision 2020-01-13 {
        type yang:date-and-time;
        config false;
    description
           "Date and time at which the symptoms history starts for this
           subservice instance, either because the subservice instance
           started at that date and time or because the symptoms before that
           were removed due
      "Initial revision.";
    reference
      "RFC xxxx: Title to a garbage collection process."; be completed";
  }
      container symptoms

  identity interface-idty {
    base service-assurance:subservice-idty;
    description
          "Symptoms for the subservice.";
        list symptom
      "Checks whether an interface is healthy.";
  }

  augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" {
          key "start-date-time id";
          config false;
    description
            "List of symptoms the subservice. While the start-date-time key is not
            necessary per se, this would get
      "Specify the entries sorted by start-date-time required parameters for easy consumption.";
          uses symptom;
        }
      } the interface-idty subservice type";
    container dependencies parameters {
      when "derived-from-or-self(../service-assurance:type, 'interface-idty')";
      description
          "configure
        "Required parameters for the dependencies between interface-idty subservice type";
      leaf device {
        type string;
        mandatory true;
        description
          "Device supporting the subservices, along with their types.";
        list dependency interface.";
      }
      leaf interface {
          key "type id";
        type string;
        mandatory true;
        description
            "List of soft dependencies
          "Name of the subservice.";
          uses subservice-dependency;
        } interface.";
      }
    }
  }
}

   <CODE ENDS>

5.

7.  Vendor-specific Subservice Extension: ietf-service-assurance-device example-service-assurance-
    device-acme YANG module

5.1.

7.1.  Tree View

   The following tree diagram [RFC8340] provides an overview of the
   ietf-service-assurance-device
   example-service-assurance-device-acme data model.

module: ietf-service-assurance-device example-service-assurance-device-acme

  augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter:
    +--rw device-idty parameters
       +--rw device                     string
       +--rw device? acme-specific-parameter    string

5.2.

7.2.  Complete Tree View

   The following tree diagram [RFC8340] provides an overview of the
   ietf-service-assurance
   ietf-service-assurance, ietf-service-assurance-device, and ietf-service-assurance-device example-
   service-assurance-device-acme data models.

module: ietf-service-assurance
  +--ro assurance-graph-version        yang:counter32
  +--ro assurance-graph-last-change    yang:date-and-time
  +--rw subservices
     +--rw subservice* [type id]
        +--rw type                                                      identityref
        +--rw id                                                        string
        +--ro last-change?                                              yang:date-and-time
        +--ro label?                                                    string
        +--rw under-maintenance?                                        boolean
        +--rw maintenance-contact                                       string
        +--rw (parameter)?
        |  +--:(service-instance-parameter)
        |  |  +--rw service-instance-parameter
        |  |     +--rw service? service          string
        |  |     +--rw instance-name    string
        |  +--:(service-assurance-device:parameters)
        |  |  +--rw service-assurance-device:parameters
        |  |     +--rw service-assurance-device:device    string
        |  +--:(example-service-assurance-device-acme:parameters)
        |  |  +--rw example-service-assurance-device-acme:parameters
        |  |     +--rw example-service-assurance-device-acme:device                     string
        |  |     +--rw instance-name? example-service-assurance-device-acme:acme-specific-parameter    string
        |  +--:(service-assurance-device:device-idty)  +--:(service-assurance-interface:parameters)
        |     +--rw service-assurance-device:device-idty service-assurance-interface:parameters
        |        +--rw service-assurance-device:device? service-assurance-interface:device       string
        |        +--rw service-assurance-interface:interface    string
        +--ro health-score?                                             uint8
        +--ro symptoms-history-start?                                   yang:date-and-time
        +--rw symptoms
        |  +--ro symptom* [start-date-time id]
        |     +--ro id                     string
        |     +--ro health-score-weight?   uint8
        |     +--ro description?           string
        |     +--ro start-date-time        yang:date-and-time
        |     +--ro stop-date-time?        yang:date-and-time
        +--rw dependencies
           +--rw dependency* [type id]
              +--rw type               -> /subservices/subservice/type
              +--rw id                 -> /subservices/subservice[type=current()/../type]/id
              +--rw dependency-type?   identityref

5.3.  Concepts

   As the number of subservices will grow over time, the YANG module is
   designed to be extensible.  A new subservice type requires the
   precise specifications of its type and expected parameters.  Let us
   illustrate the example of the new DeviceHealthy subservice type.  As
   the name implies, it monitors and reports the device health, along
   with     +--ro health-score-weight?   uint8
        |     +--ro description?           string
        |     +--ro start-date-time        yang:date-and-time
        |     +--ro stop-date-time?        yang:date-and-time
        +--rw dependencies
           +--rw dependency* [type id]
              +--rw type               -> /subservices/subservice/type
              +--rw id                 -> /subservices/subservice[type=current()/../type]/id
              +--rw dependency-type?   identityref

7.3.  Concepts

   Under some symptoms in case of degradation.

   For our DeviceHealthy circumstances, vendor-specific subservice definition, the new device-idty is
   specified, as types might be
   required.  As an inheritance from the base identity for subservices.
   This indicates to the assurance agent that we are now assuring the
   health of a device.

   The typical parameter for the configuration of the DeviceHealthy
   subservice is the name example of the device that we want this vendor-specific implementation, this
   section shows how to assure.  By
   augmenting augment the parameter choice from ietf-service-assurance YANG ietf-service-assurance-device module
   to add support for the case of the device-idty subservice type, this DeviceHealthy, specific to the ACME
   Corporation.  The new parameter is specified.

5.4. acme-specific-parameter.

7.4.  YANG Module

   <CODE BEGINS> file "ietf-service-assurance-device@2020-01-13.yang"

module ietf-service-assurance-device example-service-assurance-device-acme {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"; "urn:example:example-service-assurance-device-acme";
  prefix service-assurance-device; example-service-assurance-device-acme;

  import ietf-service-assurance {
    prefix "service-assurance"; service-assurance;
  }
  import ietf-service-assurance-device {
    prefix service-assurance-device;
  }

  organization
    "IETF NETCONF (Network Configuration) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/netconf/>
     WG List:  <mailto:netconf@ietf.org>
     Author:   Benoit Claise  <mailto:bclaise@cisco.com>  <mailto:benoit.claise@huawei.com>
     Author:   Jean Quilbeuf   <mailto:jquilbeu@cisco.com>";   <mailto:jean.quilbeuf@huawei.com>";
  description
    "This module extends the ietf-service-assurance ietf-service-assurance-device module to add
     support for the subservice DeviceHealthy.

    Checks whether a network device DeviceHealthy, specific to the ACME Corporation.

     ACME Network Device is healthy.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
     'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
     'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
     are to be interpreted as described in BCP 14 (RFC 2119)
     (RFC 8174) when, and only when, they appear in all
     capitals, as shown here.

     Copyright (c) 2020 2021 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; see the
     RFC itself for full legal notices.  ";

  revision 2021-06-28 {
    description
      "Renamed the parameters container.";
    reference
      "RFC xxxx: Title to be completed";
  }
  revision 2020-01-13 {
    description
      "Added the maintenance window concept.";
    reference
      "RFC xxxx: Title to be completed";
  }
  revision 2019-11-16 {
    description
      "Initial revision.";
    reference
      "RFC xxxx: Title to be completed";
  }

  identity device-idty device-acme-idty {
    base service-assurance:subservice-idty; service-assurance-device:device-idty;
    description
      "Network Device is healthy.";
  }

  augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" {
    description
      "Specify the required parameters for a new subservice type";
    container device-idty{ parameters {
      when "derived-from-or-self(../service-assurance:type, 'device-idty')"; 'device-acme-idty')";
      description
        "Specify the required parameters for the device-idty device-acme-idty subservice type";
      leaf device {
        type string;
        mandatory true;
        description
          "The device to monitor.";
      }
      leaf acme-specific-parameter {
        type string;
        mandatory true;
        description
          "The ACME Corporation sepcific parameter.";
      }
    }
  }

}

8.  Further Extensions: IP Connectivity and IS-IS subservices

8.1.  IP Connectivity Tree View

   The following tree diagram [RFC8340] provides an overview of the
   ietf-service-assurance-ip-connectivity data model.

module: ietf-service-assurance-ip-connectivity

  augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter:
    +--rw parameters
       +--rw device1     string
       +--rw address1    inet:ip-address
       +--rw device2     string
       +--rw address2    inet:ip-address

   To specify the connectivity that we are interested in, we specify two
   IP addresses and two devices.  The subservice type";

           leaf assures that the
   connectivity between IP address 1 on device {
               type string;
               description "The 1 and IP address 2 on
   device to monitor.";
           }
       }
  }
}

   <CODE ENDS>

6.  Subservice Extension: ietf-service-assurance-interface YANG module

6.1. 2 is healthy.

8.2.  IS-IS Tree View

   The following tree diagram [RFC8340] provides an overview of the
   ietf-service-assurance-interface
   ietf-service-assurance-is-is data model.

module: ietf-service-assurance-interface ietf-service-assurance-is-is

  augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter:
    +--rw device?      string parameters
       +--rw interface? instance-name    string

6.2.  Complete

   The parameter of this subservice is the name of the IS-IS instance to
   assure.

8.3.  Global Tree View

   The following tree diagram [RFC8340] provides an overview of the
   ietf-service-assurance, ietf-service-assurance-device, example-
   service-assurance-device-acme, ietf-service-assurance-ip-connectivity
   and ietf-
   service-assurance-interface ietf-service-assurance-is-is data models.

module: ietf-service-assurance
  +--ro assurance-graph-version        yang:counter32
  +--ro assurance-graph-last-change    yang:date-and-time
  +--rw subservices
     +--rw subservice* [type id]
        +--rw type                                                      identityref
        +--rw id                                                        string
        +--ro last-change?                                              yang:date-and-time
        +--ro label?                                                    string
        +--rw under-maintenance?                                        boolean
        +--rw maintenance-contact                                       string
        +--rw (parameter)?
        |  +--:(service-instance-parameter)
        |  |  +--rw service-instance-parameter
        |  |     +--rw service? service          string
        |  |     +--rw instance-name    string
        |  +--:(service-assurance-ip-connectivity:parameters)
        |  |  +--rw service-assurance-ip-connectivity:parameters
        |  |     +--rw service-assurance-ip-connectivity:device1     string
        |  |     +--rw service-assurance-ip-connectivity:address1    inet:ip-address
        |  |     +--rw service-assurance-ip-connectivity:device2     string
        |  |     +--rw instance-name? service-assurance-ip-connectivity:address2    inet:ip-address
        |  +--:(service-assurance-is-is:parameters)
        |  |  +--rw service-assurance-is-is:parameters
        |  |     +--rw service-assurance-is-is:instance-name    string
        |  +--:(service-assurance-device:device-idty)  +--:(service-assurance-device:parameters)
        |  |  +--rw service-assurance-device:device-idty service-assurance-device:parameters
        |  |     +--rw service-assurance-device:device? service-assurance-device:device    string
        |  +--:(service-assurance-interface:device)  +--:(example-service-assurance-device-acme:parameters)
        |  |  +--rw example-service-assurance-device-acme:parameters
        |  |     +--rw example-service-assurance-device-acme:device                     string
        |  |     +--rw service-assurance-interface:device? example-service-assurance-device-acme:acme-specific-parameter    string
        |  +--:(service-assurance-interface:interface)  +--:(service-assurance-interface:parameters)
        |     +--rw service-assurance-interface:interface? service-assurance-interface:parameters
        |        +--rw service-assurance-interface:device       string
        |        +--rw service-assurance-interface:interface    string
        +--ro health-score?                                             uint8
        +--ro symptoms-history-start?                                   yang:date-and-time
        +--rw symptoms
        |  +--ro symptom* [start-date-time id]
        |     +--ro id                     string
        |     +--ro health-score-weight?   uint8
        |     +--ro description?           string
        |     +--ro start-date-time        yang:date-and-time
        |     +--ro stop-date-time?        yang:date-and-time
        +--rw dependencies
           +--rw dependency* [type id]
              +--rw type               -> /subservices/subservice/type
              +--rw id                 -> /subservices/subservice[type=current()/../type]/id
              +--rw dependency-type?   identityref

6.3.  Concepts

   For our InterafaceHealthy

8.4.  IP Connectivity YANG Module

   <CODE BEGINS> file "ietf-service-assurance-ip-
   connectivity@2021-06-28.yang"

module ietf-service-assurance-ip-connectivity {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-ip-connectivity";
  prefix service-assurance-ip-connectivity;

  import ietf-inet-types {
    prefix inet;
  }
  import ietf-service-assurance {
    prefix service-assurance;
  }

  organization
    "IETF OPSAWG Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>
     Author:   Benoit Claise  <mailto:benoit.claise@huawei.com>
     Author:   Jean Quilbeuf   <mailto:jean.quilbeuf@huawei.com>";
  description
    "This module extends the ietf-service-assurance module to add
     support for the subservice definition, ip-connectivity.

     Checks whether the ip connectivity between two ip addresses
     belonging to two network devices is healthy.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
     'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
     'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
     are to be interpreted as described in BCP 14 (RFC 2119)
     (RFC 8174) when, and only when, they appear in all
     capitals, as shown here.

     Copyright (c) 2021 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.
     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the new interface-
   idty license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is specified, as an inheritance from part of RFC XXXX; see the base identity
     RFC itself for
   subservices.  This indicates full legal notices.  ";

  revision 2021-06-28 {
    description
      "Initial revision.";
    reference
      "RFC xxxx: Title to be completed";
  }

  identity ip-connectivity-idty {
    base service-assurance:subservice-idty;
    description
      "Checks connectivity between two IP addresses.";
  }

  augment "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" {
    description
      "Specify the assurance agent that we are now
   assuring required parameters for the health of an interface.

   The typical ip-connectivity-idty subservice type";
    container parameters {
      when "derived-from-or-self(../service-assurance:type, 'ip-connectivity-idty')";
      description
        "Required parameters for the configuration ip-connectivity-idty subservice type";
      leaf device1 {
        type string;
        mandatory true;
        description
          "Device at the first end of the InterfaceHealthy
   subservice are connection.";
      }
      leaf address1 {
        type inet:ip-address;
        mandatory true;
        description
          "Address at the name first end of the device and, on that specific device, a
   specific interface.  By augmenting connection.";
      }
      leaf device2 {
        type string;
        mandatory true;
        description
          "Device at the parameter choice from ietf-
   service-assurance YANG module for second end of the case connection.";
      }
      leaf address2 {
        type inet:ip-address;
        mandatory true;
        description
          "Address at the second end of the interface-idty
   subservice type, those two new parameter are specified.

6.4. connection.";

      }
    }
  }
}

   <CODE ENDS>

8.5.  IS-IS YANG Module

   <CODE BEGINS> file "ietf-service-assurance-interface@2020-01-13.yang" "ietf-service-assurance-is-is@2021-06-28.yang"

module ietf-service-assurance-interface ietf-service-assurance-is-is {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface"; "urn:ietf:params:xml:ns:yang:ietf-service-assurance-is-is";
  prefix service-assurance-interface; service-assurance-is-is;

  import ietf-service-assurance {
    prefix "service-assurance"; service-assurance;
  }

  organization
    "IETF OPSAWG NETCONF (Network Configuration) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>   <https://datatracker.ietf.org/wg/netconf/>
     WG List:  <mailto:opsawg@ietf.org>  <mailto:netconf@ietf.org>
     Author:   Benoit Claise  <mailto:bclaise@cisco.com>  <mailto:benoit.claise@huawei.com>
     Author:   Jean Quilbeuf   <mailto:jquilbeu@cisco.com>";  <mailto:jean.quilbeuf@huawei.com>";
  description
    "This module extends the ietf-service-assurance module to add
     support for the subservice InterfaceHealthy. IS-ISHealthy.

     Checks whether an interface IS-IS instance is healthy.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
     'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
     'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
     are to be interpreted as described in BCP 14 (RFC 2119)
     (RFC 8174) when, and only when, they appear in all
     capitals, as shown here.

     Copyright (c) 2020 2021 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Simplified BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).
     This version of this YANG module is part of RFC XXXX; see the
     RFC itself for full legal notices.  ";

  revision 2020-01-13 2021-06-28 {
    description
      "Initial revision.";
    reference
      "RFC xxxx: Title to be completed";
  }

  identity interface-idty is-is-idty {
    base service-assurance:subservice-idty;
    description "Checks whether an interface is healthy.";
      "Health of IS-IS routing protocol.";
  }

  augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter "/service-assurance:subservices/service-assurance:subservice/service-assurance:parameter" {
       when "derived-from-or-self(service-assurance:type, 'interface-idty')";
    description
      "Specify the required parameters for the interface-idty a new subservice type";

       leaf device
    container parameters {
           type string;
      when "derived-from-or-self(../service-assurance:type, 'is-is-idty')";
      description "Device supporting
        "Specify the interface.";
       } required parameters for the IS-IS subservice type";
      leaf interface instance-name {
        type string;
        mandatory true;
        description "Name of the interface.";
          "The instance to monitor.";
      }
    }
  }
}

   <CODE ENDS>

7.  Vendor-specific

9.  Guidelines for Specific Subservice Extension: example-service-assurance-
    device-acme Extension

   The base YANG module

7.1.  Tree View

   The following tree diagram [RFC8340] provides an overview defined in Section 4.3 only defines a single
   type of the
   example-service-assurance-device-acme data model.

module: example-service-assurance-device-acme
  augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter:
    +--rw acme-device-idty
       +--rw device?                    string
       +--rw acme-specific-parameter?   string

7.2.  Complete Tree View

   The following tree diagram [RFC8340] provides an overview subservices that represent service instances.  As explained
   above, this model is meant to be augmented so that a variety of the
   ietf-service-assurance, ietf-service-assurance-device, and example-
   service-assurance-device-acme data models.

module: ietf-service-assurance
  +--ro assurance-graph-version        yang:counter32
  +--ro assurance-graph-last-change    yang:date-and-time
  +--rw
   subservices
     +--rw subservice* [type id]
        +--rw type                                                            identityref
        +--rw id                                                              string
        +--ro last-change?                                                    yang:date-and-time
        +--ro label?                                                          string
        +--rw under-maintenance?                                              boolean
        +--rw maintenance-contact                                             string
        +--rw (parameter)?
        |  +--:(service-instance-parameter)
        |  |  +--rw service-instance-parameter
        |  |     +--rw service?         string
        |  |     +--rw instance-name?   string
        |  +--:(service-assurance-device:device-idty)
        |  |  +--rw service-assurance-device:device-idty
        |  |     +--rw service-assurance-device:device?   string
        |  +--:(service-assurance-interface:device)
        |  |  +--rw service-assurance-interface:device?                       string
        |  +--:(service-assurance-interface:interface)
        |  |  +--rw service-assurance-interface:interface?                    string
        |  +--:(example-service-assurance-device-acme:acme-device-idty)
        |     +--rw example-service-assurance-device-acme:acme-device-idty
        |        +--rw example-service-assurance-device-acme:device?                    string
        |        +--rw example-service-assurance-device-acme:acme-specific-parameter?   string
        +--ro health-score?                                                   uint8
        +--ro symptoms-history-start?                                         yang:date-and-time
        +--rw symptoms
        |  +--ro symptom* [start-date-time id]
        |     +--ro id                     string
        |     +--ro health-score-weight?   uint8
        |     +--ro description?           string
        |     +--ro start-date-time        yang:date-and-time
        |     +--ro stop-date-time?        yang:date-and-time
        +--rw dependencies
           +--rw dependency* [type id]
              +--rw type               -> /subservices/subservice/type
              +--rw id                 -> /subservices/subservice[type=current()/../type]/id
              +--rw dependency-type?   identityref

7.3.  Concepts

   Under can be used in the assurance graph.  In this section, we
   propose some circumstances, vendor-specific guidelines in order to build theses extensions.

   First, the specific subservice types might must be
   required.  As given an example of this vendor-specific implementation, this
   section shows how adequate unique short
   name that will be used to augment form longer names (e.g. module name, prefix
   ...) appearing in the YANG module.  The short name identifies the
   type of subpart of feature that the ietf-service-assurance-device module
   to add support subservice will represent, for
   instance if the subservice DeviceHealthy, specific to will assure the ACME
   Corporation.  The new parameter health of a network
   interafce then "interface" is acme-specific-parameter.

7.4.  YANG Module

module example-service-assurance-device-acme {
  yang-version 1.1;
  namespace "urn:example:example-service-assurance-device-acme";
  prefix example-service-assurance-device-acme;

  import ietf-service-assurance {
    prefix "service-assurance";
  }

  import ietf-service-assurance-device {
    prefix "service-assurance-device";
  }

  organization
    "IETF NETCONF (Network Configuration) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/netconf/>
     WG List:  <mailto:netconf@ietf.org>
     Author:   Benoit Claise  <mailto:bclaise@cisco.com>
     Author:   Jean Quilbeuf   <mailto:jquilbeu@cisco.com>";
  description
   "This module extends the ietf-service-assurance-device module to add
    support for an adequate short name.  If the
   subservice DeviceHealthy, specific to will assure the ACME Corporation.

    ACME Network Device IS-IS routing protocol, then "is-is" is healthy. an
   adequate short name.  The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
    'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
    'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' short name must be in kebab-case.

   In this document
    are section, by subservice YANG module, we mean "YANG module that
   extends ieft-service-assurance in order to define a specific
   subservice".

9.1.  Module Name

   For subservice YANG modules vetted by the IETF, the module name
   should be interpreted as described in BCP 14 (RFC 2119)
    (RFC 8174) when, and only when, "ieft-service-assurance-" followed by the short name.  For
   instance, "ietf-service-assurance-interface" or "ietf-service-
   assurance-is-is".

   For subservice YANG module that are directly provided by vendors, we
   propose that they appear use the company in all
    capitals, as shown here.

    Copyright (c) 2019 IETF Trust the prefix.  For example, the
   prefix for the company "acme" would be "acme-assurance-" and the persons identified as
    authors of YANG
   modules would be "acme-assurance-interface", "acme-assurance-is-is",
   etc.

9.2.  Module Namespace

   For subservice YANG modules vetted by the IETF, the module namespace
   should be "urn:ietf:params:xml:ns:yang:ietf-service-assurance-"
   followed by the short name.  For instance,
   "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface" or
   "urn:ietf:params:xml:ns:yang:ietf-service-assurance-is-is".

   For subservice YANG module that are directly provided by vendors, a
   similar pattern can be used with the prefix being a namespace
   controlled by the vendor.

9.3.  Module Prefix

   For subservice YANG modules vetted by the IETF, the module prefix
   should be "service-assurance-" followed by the code.  All rights reserved.

    Redistribution and use in source and binary forms, with short name.  For
   instance, "service-assurance-interface" or
    without modification, is permitted pursuant to, and subject "service-assurance-is-is".

   For subservice YANG module that are directly provided by vendors, the
   same pattern can be used provided it does not conflict with an
   imported prefix.

9.4.  Subservice Specific Identity

   Each auqment specific to a subservice must define an identity
   representing the license terms contained in, type of subpart or features of the Simplified BSD License
    set forth network system
   that are assured by the subservice.  As required in the "ietf-
   service-assurance" module (see Section 4.c of 4.3), that identity must be
   based on the IETF Trust's Legal Provisions
    Relating to IETF Documents
    (https://trustee.ietf.org/license-info).

    This version of this "subservice-idty" identity.

   For subservice YANG module is part of RFC XXXX; see modules vetted by the
    RFC itself for full legal notices.  ";

  revision 2020-01-13 {
    description
      "Added IETF, the maintenance window concept.";
    reference
      "RFC xxxx: Title to be completed";
  }

  revision 2019-11-16 {
    description
      "Initial revision.";
    reference
        "RFC xxxx: Title to be completed";
  } subservice
   specific identity device-acme-idty {
    base service-assurance-device:device-idty;
    description "Network Device is healthy.";
  }

  augment /service-assurance:subservices/service-assurance:subservice/service-assurance:parameter {
       description
         "Specify should be the short name of the required parameters for a new subservice type";
       container acme-device-idty{
           when "derived-from-or-self(../service-assurance:type, 'device-acme-idty')";
           description
             "Specify followed
   by "-idty".  For instance, "interface-idty" or "is-is-identity".

   For subservice YANG module that are directly provided by vendors, the
   same pattern can be used.

9.5.  Parameters

   For subservice YANG modules vetted by the IETF, the required parameters for
   specific to the device-acme-idty subservice type";

           leaf device {
               type string;
               description "The device should be placed in a container named
   "parameters".  That container must be used to monitor.";
           }

           leaf acme-specific-parameter {
               type string;
               description "The ACME Corporation sepcific parameter.";
           }
       }
  }
}

8. augment the "parameter"
   choice from the module "ietf-service-assurance" (see Section 4.3 and
   that augment must be guarded so that it is effective only for
   subservice instance whose type is the subservice specific identity
   from Section 9.4.

   For subservice YANG module that are directly provided by vendors, the
   same pattern can be used.

10.  Security Considerations

   The YANG module specified in this document defines a schema for data
   that is designed to be accessed via network management protocols such
   as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
   is the secure transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS
   [RFC8446].

   The Network Configuration Access Control Model (NACM) [RFC8341]
   provides the means to restrict access for particular NETCONF or
   RESTCONF users to a preconfigured subset of all available NETCONF or
   RESTCONF protocol operations and content.

   There are a number of data nodes defined in this YANG module that are
   writable/ creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g., edit-config)
   to these data nodes without proper protection can have a negative
   effect on network operations.  These are the subtrees and data nodes
   and their sensitivity/vulnerability:

   o  /subservices/subservice/type

   o  /subservices/subservice/id

   o  /subservices/subservice/under-maintenance

   o  /subservices/subservice/maintenance-contact

9.

11.  IANA Considerations

9.1.

11.1.  The IETF XML Registry

   This document registers two URIs in the IETF XML registry [RFC3688].
   Following the format in [RFC3688], the following registrations are
   requested:

      URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance
      Registrant Contact: The NETCONF WG of the IETF.
      XML: N/A, the requested URI is an XML namespace.

      URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-device
      Registrant Contact: The NETCONF WG of the IETF.
      XML: N/A, the requested URI is an XML namespace.

      URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface
      Registrant Contact: The NETCONF WG of the IETF.
      XML: N/A, the requested URI is an XML namespace.

9.2.

11.2.  The YANG Module Names Registry

   This document registers three YANG modules in the YANG Module Names
   registry [RFC7950].  Following the format in [RFC7950], the the
   following registrations are requested:

  name:       ietf-service-assurance
  namespace:  urn:ietf:params:xml:ns:yang:ietf-service-assurance
  prefix:     inc
  reference:  RFC XXXX

  name:       ietf-service-assurance-device
  namespace:  urn:ietf:params:xml:ns:yang:ietf-service-assurance-device
  prefix:     inc
  reference:  RFC XXXX

  name:       ietf-service-assurance-interface
  namespace:  urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface
  prefix:     inc
  reference:  RFC XXXX

10.

12.  Open Issues

      -None

11.

13.  References

11.1.

13.1.  Normative References

   [draft-claise-opsawg-service-assurance-architecture]

   [I-D.ietf-opsawg-service-assurance-architecture]
              Claise, B. and J. B., Quilbeuf, "draft-claise-opsawg-service-
              assurance-architecture", J., Lopez, D., Voyer, D., and T.
              Arumugam, "draft-claise-opsawg-service-assurance-
              architecture", 2020.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              RFC 7950, DOI 10.17487/RFC7950, August 2016,
              <https://www.rfc-editor.org/info/rfc7950>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

11.2.

13.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC7895]  Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
              Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
              <https://www.rfc-editor.org/info/rfc7895>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
              <https://www.rfc-editor.org/info/rfc8340>.

13.3.  URIs

   [1] https://yangson.labs.nic.cz/

Appendix A.  Changes between revisions

   v04 - v05

   o  Added  Example of YANG instances

   This section contains examples of YANG instances that conform to the concept
   YANG modules.  The validity of symptoms-history-start

   o  Changed label these data instances has been checked
   using yangson [1].  Yangson requires a YANG library [RFC7895] to description, under symptoms.  This was confusing
      as there was two labels
   define the complete model against which the data instance must be
   validated.  We provide in Appendix B the JSON library file, named
   "ietf-service-assurance-library.json", that we used for validation.

   We provide below the contents of the file
   "example_configuration_instance.json" which contains the
   configuration data that models

   v03 - v04

   o  Add the interface subservice, Figure 2 of

   [I-D.ietf-opsawg-service-assurance-architecture].  The instance can
   be validated with two parameters

   v02 yangson by using the invocation "yangson -v
   example_configuration_instance.json ietf-service-assurance-
   library.json", assuming all the files (YANG and JSON) defined in this
   draft reside in the current folder.

   <CODE BEGINS> file "example_configuration_instance.json"

{
  "ietf-service-assurance:subservices": {
    "subservice": [
      {
        "type": "service-instance-idty",
        "id": "simple-tunnel/example",
        "service-instance-parameter": {
          "service": "simple-tunnel",
          "instance-name": "example"
        },
        "dependencies": {
          "dependency": [
            {
              "type": "ietf-service-assurance-interface:interface-idty",
              "id": "interface/peer1/tunnel0",
              "dependency-type": "impacting-dependency"
            },
            {
              "type": "ietf-service-assurance-interface:interface-idty",
              "id": "interface/peer2/tunnel9",
              "dependency-type": "impacting-dependency"
            },
            {
              "type": "ietf-service-assurance-ip-connectivity:ip-connectivity-idty",
              "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2",
              "dependency-type": "impacting-dependency"
            }
          ]
        }
      },
      {
        "type": "ietf-service-assurance-ip-connectivity:ip-connectivity-idty",
        "id": "connectivity/peer1/2001:db8::1/peer2/2001:db8::2",
        "ietf-service-assurance-ip-connectivity:parameters": {
          "device1": "Peer1",
          "address1": "2001:db8::1",
          "device2": "Peer2",
          "address2": "2001:db8::2"
        },
        "dependencies": {
          "dependency": [
            {
              "type": "ietf-service-assurance-interface:interface-idty",
              "id": "interface/peer1/physical0",
              "dependency-type": "impacting-dependency"
            },
            {
              "type": "ietf-service-assurance-interface:interface-idty",
              "id": "interface/peer2/physical5",
              "dependency-type": "impacting-dependency"
            },
            {
              "type": "ietf-service-assurance-is-is:is-is-idty",
              "id": "is-is/instance1",
              "dependency-type": "impacting-dependency"
            }
          ]
        }
      },
      {
        "type": "ietf-service-assurance-is-is:is-is-idty",
        "id": "is-is/instance1",
        "ietf-service-assurance-is-is:parameters": {
          "instance-name": "instance1"
        }
      },
      {
        "type": "ietf-service-assurance-interface:interface-idty",
        "id": "interface/peer1/tunnel0",
        "ietf-service-assurance-interface:parameters": {
          "device": "Peer1",
          "interface": "tunnel0"
        },
        "dependencies": {
          "dependency": [
            {
              "type": "ietf-service-assurance-interface:interface-idty",
              "id": "interface/peer1/physical0",
              "dependency-type": "impacting-dependency"
            }
          ]
        }
      },
      {
        "type": "ietf-service-assurance-interface:interface-idty",
        "id": "interface/peer1/physical0",
        "ietf-service-assurance-interface:parameters": {
          "device": "Peer1",
          "interface": "physical0"
        },
        "dependencies": {
          "dependency": [
            {
              "type": "ietf-service-assurance-device:device-idty",
              "id": "interface/peer1",
              "dependency-type": "impacting-dependency"
            }
          ]
        }
      },
      {
        "type": "ietf-service-assurance-device:device-idty",
        "id": "interface/peer1",
        "ietf-service-assurance-device:parameters": {
          "device": "Peer1"
        }
      },
      {
        "type": "ietf-service-assurance-interface:interface-idty",
        "id": "interface/peer2/tunnel9",
        "ietf-service-assurance-interface:parameters": {
          "device": "Peer2",
          "interface": "tunnel9"
        },
        "dependencies": {
          "dependency": [
            {
              "type": "ietf-service-assurance-interface:interface-idty",
              "id": "interface/peer2/physical5",
              "dependency-type": "impacting-dependency"
            }
          ]
        }
      },
      {
        "type": "ietf-service-assurance-interface:interface-idty",
        "id": "interface/peer2/physical5",
        "ietf-service-assurance-interface:parameters": {
          "device": "Peer2",
          "interface": "physical5"
        },
        "dependencies": {
          "dependency": [
            {
              "type": "ietf-service-assurance-device:device-idty",
              "id": "interface/peer2",
              "dependency-type": "impacting-dependency"
            }
          ]
        }
      },
      {
        "type": "ietf-service-assurance-device:device-idty",
        "id": "interface/peer2",
        "ietf-service-assurance-device:parameters": {
          "device": "Peer2"
        }
      }
    ]
  }
}

   <CODE ENDS>

Appendix B.  YANG Library for Service Assurance

   This section provides the JSON encoding of the YANG library [RFC7895]
   listing all modules defined in this draft and their dependencies.
   This library can be used to validate data instances using yangson, as
   explained in the previous section.

   <CODE BEGINS> file "ietf-service-assurance-library.json"

{
  "ietf-yang-library:modules-state": {
    "module-set-id": "ietf-service-assurance@2020-01-13",
    "module": [
      {
        "name": "ietf-service-assurance",
        "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance",
        "revision": "2021-06-28",
        "conformance-type": "implement"
      },
      {
        "name": "ietf-service-assurance-device",
        "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device",
        "revision": "2021-06-28",
        "conformance-type": "implement"
      },
      {
        "name": "ietf-service-assurance-interface",
        "namespace": "urn:ietf:params:xml:ns:yang:ietf-service-assurance-interface",
        "revision": "2021-06-28",
        "conformance-type": "implement"

      },
      {
        "name": "example-service-assurance-device-acme",
        "namespace": "urn:example:example-service-assurance-device-acme",
        "revision": "2021-06-28",
        "conformance-type": "implement"
      },
      {
        "name": "ietf-service-assurance-is-is",
        "namespace": "urn:ietf:payams:xml:ns:yang:ietf-service-assurance-is-is",
        "revision": "2021-06-28",
        "conformance-type": "implement"
      },
      {
        "name": "ietf-service-assurance-ip-connectivity",
        "namespace": "urn:ietf:payams:xml:ns:yang:ietf-service-assurance-ip-connectivity",
        "revision": "2021-06-28",
        "conformance-type": "implement"
      },
      {
        "name": "ietf-yang-types",
        "namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
        "revision": "2021-04-14",
        "conformance-type": "import"
      },
      {
        "name": "ietf-inet-types",
        "namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
        "revision": "2021-02-22",
        "conformance-type": "import"
      }
    ]
  }
}

   <CODE ENDS>

Appendix C.  Changes between revisions

   v00 - v03 v01

   o  Added the maintenace window concepts
   v01 - v02 needed subservice to model example from architecture draft

   o  Improved leaf  Added guideline section for naming models

   o  Clarified some concepts: symptoms, dependency

   v00 - v01

   o  Terminology clarifications  Added data instance examples and validation procedure
   o  Provide example of impacting versus impacted dependencies  Added the "parameters" container in the interface YANG module to
      correct a bug.

Acknowledgements

   The authors would like to thank Jan Lindblad for his help during the
   design of these YANG modules.  The authors would like to thank
   Stephane Litkowski and Charles Eckel for their reviews.

Authors' Addresses

   Benoit Claise
   Huawei

   Email: benoit.claise@huawei.com

   Jean Quilbeuf
   Independent
   Huawei

   Email: jean@quilbeuf.net jean.quilbeuf@huawei.com

   Paolo Lucente
   NTT
   Siriusdreef 70-72
   Hoofddorp, WT  2132
   Netherlands

   Email: paolo@ntt.net

   Paolo Fasano
   TIM S.p.A
   via G. Reiss Romoli, 274
   10148 Torino
   Italy

   Email: paolo2.fasano@telecomitalia.it

   Thangam Arumugam
   Cisco Systems, Inc.
   Milpitas (California)
   United States

   Email: tarumuga@cisco.com