Liaison statement
LS on need for modeling isInvariant and SystemCreated in YANG

1.1 3GPP SA5 Introduction

The 3rd Generation Partnership Project (3GPP) unites seven telecommunications
standard development organizations (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
Its work includes development and maintenance of standards for
    GSM and related 2G and 2.5G standards, including GPRS and EDGE
    UMTS and related 3G standards, including HSPA and HSPA+
    LTE and related 4G standards, including LTE Advanced and LTE Advanced Pro
    5G NR and related 5G standards, including 5G-Advanced
    An evolved IP Multimedia Subsystem (IMS) developed in an access independent
    manner
3GPP SA5 workgroup specifies Management, Orchestration and Charging
requirements, solutions, and protocol specific definitions. The solutions
include architecture, service definitions and data definitions.

3GPP SA5 defines OAM information and data models. Stage 2 information models
are defined based on a UML subset as defined in 3GPP TS 32.156[3]. The base
concepts used are classes/objects arranged in a tree shaped containment
hierarchy and attributes that are contained in these classes/objects.

1.2 3GPP SA5 using YANG for 5G – a major YANG community

3GPP introduced YANG as one of the stage3 data models for 5G.
Stage 3 data models (Solution Sets) are defined in YANG and in
JsonSchema/OpenApi for 5G NR and related 5G standards, including 5G-Advanced.
This document considers the YANG models but does not handle the OpenApi models.
According to 3GPP rules and processes Stage 3 data models should be a direct
mapping of the stage 2 information models. Stage 3 should not add or remove
data or data handling concepts to stage 2 definitions. While mapping 3GPP Stage
2 models to any solution set is necessarily imperfect, the goal is to follow
stage 2 concepts as closely as possible.

3GPP TS 32.160[4] clause 6.2 defines how to map stage 2 information models to
YANG. Classes are mapped to YANG lists. Attributes are mapped to YANG leaves,
leaf-lists and lists contained under the list of the class. The most important
3GPP Stage 2 and Stage 3 models are currently defined in 3GPP TS 28.622[5],
28.623[6] and 28.541[7].

3GPP Stage 2 models include modeling concepts (including isInvariant and
SystemCreated Classes) that currently cannot be mapped to IETF defined YANG
statements. So a solution to represent the isInvariant and SystemCreated
properties in IETF defined YANG statements is needed to support 3GPP stage3
YANG data model.

1.2.1   isInvariant

We propose to formally document as a YANG extension a model handling behavior
(inVariant) that is allowed today in YANG and which has been used in 3GPP for a
long time. 3GPP TS 32.156[3] clause 5.2.1.1 defines the isInvariant property
for attributes. An attribute with the isInvariant=True property may be assigned
a value when the containing Object is created, but the value of the attribute
cannot be modified later. The only way to modify the attribute value is to
delete the containing object and re-create it with the same attribute having a
different value. However, such a delete/recreate sequence may often have
undesirable side-effects e.g., traffic disturbance. RFC 7950 either allows a
data node to be written or not (config true/false) but does not differentiate
between the initial creation of a data node or a later modification. YANG
allows the server to refuse any modification for any reason even if a data node
is config=true, so YANG allows behavior according to the 3GPP isInvariant=True
property. It is needed to formally document this behavior (which is known
already at design/implementation time) in the YANG models so that model driven
tools/SW can understand it.

1.2.2   SystemCreated Classes

We propose to formally document as a YANG extension a model handling behavior
(SystemCreated) that is allowed today in YANG and which has been used in 3GPP
for a long time. In TS 28.622[5] and TS 28.541[7] several Classes are defined
as created and deleted by the system (MnS Provider in 3GPP terms that is the
server in YANG terminology).  Managed Object Instances of SystemCreated classes
cannot be created or deleted by the client (MnS_Consumer). SystemCreated
classes in many cases contain writable attributes. SystemCreated classes
include ThresholdMonitor, HeartbeatControl, NtfSubscriptionControl, AlarmList,
TraceJob, PerfMetricJob, Files, File, Dynamic5QISet.

All 3GPP classes are mapped to YANG lists. Attributes are mapped to YANG
leaves, leaf-lists and lists contained under the list of the class.

According to RFC 7950 the only way to declare that entries in a list
(representing a SystemCreated object) cannot be added or deleted is to mark the
list as config=false. However, a config=false list cannot contain writable
(config=true) data nodes.

YANG allows marking the list of the class as config=true and defining writable
(config=true) data nodes (attributes) below it. YANG also allows the server to
refuse any modification for any reason even if a data node is config=true, so
YANG allows the server to reject the creation/deletion of config=true list
entries. YANG allows behavior according to the 3GPP SystemCreated concept. It
is needed to formally document this behavior (which is known already at
design/implementation time) in the YANG models so that model driven tools/SW
can understand it.

1.3     ITU-T usage of the immutable concept

ITU-T uses similar concepts with an imperfect YANG mapping. The modeling
concepts of isInvariant (a Boolean property that indicates whether an attribute
value can be changed after it has been created) and writeAllowed (an
Enumeration that indicates various restrictions on creating and setting a
value) cannot be modeled in YANG today. The concepts would be supported if the
concept of immutable was added to YANG. See G.8052.1[9], G.8152.2, and G.874.1
for examples of specification of a model using isInvariant and writeAllowed but
including an incomplete mapping in the accompanying YANG. The properties are
only visible in the UML model as YANG support is missing. See also [10].

1.4     IETF Solution preferred

While we raise the issue, in order to document 3GPP concepts, we seek an IETF
ratified solution because • IETF ratified solutions are more likely to be
implemented by YANG/Netconf SW tools. • 3GPP represents a significant standard,
vendor, and user community for YANG. • The invariant and SystemCreated concepts
are not unique to 3GPP. They are used by other standard organizations and
vendors. • Participants in IETF itself have identified several similar
use-cases independent of 3GPP. See [2].

• To avoid using vendor or standard specific solutions for a common problem:
 o 3GPP uses both above concepts and has already defined a YANG extension for
 inVariant. o ITU-T uses the invariant concept o Ericsson has a similar
 extension defined o YumaPro has a similar extension defined
 yuma-ncx:user-write. o Nokia has a similar extension defined sros-ext:
 immutable o Huawei also has the very similar extension defined as ext:
 operation-exclude (see
 https://github.com/Huawei/yang/blob/master/network-router/8.22.0/ne8000-x/huawei-extension.yang)
 o Cisco has isInvariant=true data nodes in some of it’s YANG models o Junos OS
 provides a hidden and immutable configuration group called junos-defaults that
 is automatically applied to the configuration of your device.

3GPP SA5 sees draft-ma-netmod-immutable-flag [2] as a potential solution.
2 References
[1] IETF RFC 7950 he YANG 1.1 Data Modeling Language
[2] draft-ma-netmod-immutable-flag  YANG Extension and Metadata Annotation for
Immutable Flag [3] 3GPP TS 32.156 Telecommunication management; Fixed Mobile
Convergence (FMC) Model repertoire [4] 3GPP TS 32.160 Management and
orchestration; Management service template [5] 3GPP TS 28.622 Telecommunication
management; Generic Network Resource Model (NRM) Integration Reference Point
(IRP); Information Service (IS) [6] 3GPP TS 28.623 Telecommunication
management; Generic Network Resource Model (NRM) Integration Reference Point
(IRP); Solution Set (SS) definitions [7] 3GPP TS 28.541 Management and
orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3 [8] 3GPP
YANG module _3gpp-common-yang-extensions.yang [9] ITU-T G.8052.1/Y.1346.1  
Operation, administration, maintenance (OAM) management information and data
models for the Ethernet-transport network element [10] ONF TR-531 v1.1.03
February 3, 2023,  UML to YANG Mapping Guidelines

3 Actions

To IETF Netmod WG

ACTION:  3GPP SA5 respectfully asks NETMOD WG to consider 3GPP SA5 workgroup’s
strong requirement for a solution to represent the isInvariant and
SystemCreated properties in an IETF ratified manner.

3 Dates of next TSG SA WG 5 meetings

SA5#147         27 February - 3rd March 2023    Athens, GR
SA5#148-e       17th – 21st April 2023          Online