System-defined Configuration

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 2 April 2025.¶

Copyright Notice

Copyright (c) 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The Network Management Datastore Architecture (NMDA) [RFC8342] defines system configuration as the configuration that is supplied by the device itself and appears in <operational> when it is in use (Figure 2 in [RFC8342]).¶

However, there is a desire to enable a server to better expose the system configuration, regardless of whether it is in use. For example, some implementations defines the system configuration which must be referenced to be active. NETCONF/RESTCONF clients can benefit from a standard mechanism to retrieve what system configuration is available on a server.¶

Some servers allow the descendant nodes of system-defined configuration to be configured or modified. For example, the system configuration may contain an almost empty physical interface, while the client needs to be able to add, modify, or remove a number of descendant nodes. Some descendant nodes may not be modifiable (e.g., the interface "type" set by the system).¶

This document updates the NMDA defined in [RFC8342] with a read-only conventional configuration datastore called "system" to expose system-defined configuration. The solution enables configuration explicitly created by the clients to reference nodes defined in <system>, override system-provided values, and configure descendant nodes of system-defined configuration.¶

The solution defined in this document requires the use of NMDA for both clients and servers. Conformance to this document requires NMDA servers implement the "ietf-system-datastore" YANG module (Section 8).¶

2. Kinds of System Configuration

This document defines two types of system configuration. Configuration that is immediately-present and configuration that is conditionally-present. These types of system configuration are described in Section 2.1 and Section 2.2, respectively.¶

3. The System Configuration Datastore (<system>)

Following guidelines for defining datastores in the Appendix A of [RFC8342], this document introduces a new datastore resource named "system" that represents the system configuration. NMDA servers compliant with this document MUST implement a system configuration datastore, and they SHOULD also implement <intended>.¶

• Name: "system".¶

• YANG modules: all.¶

• YANG nodes: all "config true" data nodes up to the root of the tree, generated by the system.¶

• Management operations: The datastore can be read using network management protocols such as NETCONF and RESTCONF, but its contents cannot be changed by manage operations via NETCONF and RESTCONF protocols.¶

• Origin: This document does not define any new origin identity. The "system" identity of origin metadata annotation [RFC7952] is used to indicate the origin of a data item provided by the system.¶

• Protocols: YANG-driven management protocols, such as NETCONF and RESTCONF.¶

• Defining YANG module: "ietf-system-datastore" (Section 8).¶

The system configuration datastore doesn't persist across reboots.¶

4. Conceptual Model of Datastores

Clients may provide configuration nodes that reference nodes defined in <system>, override system-provided values, and configure descendant nodes of system-defined configuration in <running>, as detailed in Section 6.¶

To ensure the validity of <intended>, configuration in <running> is merged with <system> to become <intended>, in which process, configuration appearing in <running> takes precedence over the same node in <system>. Since it is unspecified how to merge configuration before transformations, if <system> or <running> includes configuration that requires further transformation (e.g., template expansion, removal of inactive configuration defined in [RFC8342]) before it can be applied, configuration transformations MUST be performed before <running> is merged with <system>.¶

Whenever configuration in <system> changes, the server MUST also immediately update and validate <intended>.¶

As a result, Figure 2 in Section 5 of [RFC8342] is updated with the below conceptual model of datastores which incorporates the system configuration datastore.¶

               +-------------+                 +-----------+
               | <candidate> |                 | <startup> |
               |  (ct, rw)   |<---+      +---->| (ct, rw)  |
               +-------------+    |      |     +-----------+
                      |           |      |           |
+-----------+         |        +-----------+         |
| <system>  |         +------->| <running> |<--------+
| (ct, ro)  |                  | (ct, rw)  |
+-----------+                  +-----------+
     |                              |
     |                              |
     |                              | // configuration transformations,
     +--------------+---------------+ // e.g., removal of nodes marked
                    |                 // as "inactive", expansion of
                    |                 // templates
                    v
              +------------+
              | <intended> |  // subject to validation
              | (ct, ro)   |
              +------------+
                     |       // changes applied, subject to
                     |       // local factors, e.g., missing
                     |       // resources, delays
 dynamic             |
 configuration       |   +-------- learned configuration
 datastores -----+   |   +-------- default configuration
                 |   |   |
                 v   v   v
             +---------------+
             | <operational> | <-- system state
             | (ct + cf, ro) |
             +---------------+

ct = config true; cf = config false
rw = read-write; ro = read-only
boxes denote named datastores

Configuration in <system> is undeletable to clients (e.g., a system-defined list entry can never be removed), even though a node defined in <system> may be overridden in <running>. If it is desired to enable a client to delete system configuration, it can be approximated using <factory-default>, as described in Section 7.1. If system initializes a value for a particular leaf which is overridden by the client with a different value in <running> (Section 6.3), the node in <running> may be removed later, in which case system-initialized value defined in <system> may still be in use and appear in <operational>.¶

6. Dynamic Behaviors

8. The "ietf-system-datastore" Module

Identities:
    +--- datastore
    |  +--- conventional
    |  |  +--- running
    |  |  +--- candidate
    |  |  +--- startup
    |  |  +--- system
    |  |  +--- intended
    |  +--- dynamic
    |  +--- operational

module ietf-system-datastore {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-system-datastore";
  prefix sysds;

  import ietf-datastores {
    prefix ds;
    reference
      "RFC 8342: Network Management Datastore Architecture(NMDA)";
  }

  organization
    "IETF NETMOD (Network Modeling) Working Group";
  contact
    "WG Web:   https://datatracker.ietf.org/wg/netmod/
     WG List:  NETMOD WG list <mailto:[email protected]>

     Author: Qiufang Ma
             <mailto:[email protected]>
     Author: Qin Wu
             <mailto:[email protected]>
     Author: Chong Feng
             <mailto:[email protected]>";
  description
    "This module defines a new YANG identity that uses the
     ds:conventional identity defined in [RFC8342].

     Copyright (c) 2024 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 Revised
     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
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
     itself for full legal notices.";

  revision 2024-09-29 {
    description
      "Initial version.";
    reference
      "RFC XXXX: System-defined Configuration";
  }

  identity system {
    base ds:conventional;
    description
      "This read-only datastore contains the configuration
       provided by the system itself.";
  }
}

9. IANA Considerations

   URI: urn:ietf:params:xml:ns:yang:ietf-system-datastore
   Registrant Contact: The IESG.
   XML: N/A, the requested URIs are XML namespaces.

      name: ietf-system-datastore
      prefix: sysds
      namespace: urn:ietf:params:xml:ns:yang:ietf-system-datatstore
      maintained by IANA? N
      RFC: XXXX // RFC Ed.: replace XXXX and remove this comment

10. Security Considerations

This section is modeled after the template described in Section 3.7 of [I-D.ietf-netmod-rfc8407bis].¶

The "ietf-system-datastore" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have to use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and have to use mutual authentication.¶

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.¶

The YANG module only defines a identity that uses the "ds:conventional" identity as its base. The module by itself does not expose any data nodes that are writable, date nodes that contain read-only state, or RPCs. As such, there are no additional security issues related to the YANG module that need to be considered.¶

Acknowledgements

The authors would like to thank for following for discussions and providing input to this document: Balazs Lengyel, Robert Wilton, Juergen Schoenwaelder, Andy Bierman, Martin Bjorklund, Mohamed Boucadair, Michal Vaško, Alexander Clemm, and Timothy Carey.¶

Authors' Addresses