module o-ran-smo-teiv-common-yang-extensions {
yang-version 1.1;
namespace "urn:o-ran:smo-teiv-common-yang-extensions";
prefix or-teiv-yext;
organization "ORAN";
contact "The Authors";
description
"Topology and Inventory YANG extensions model.
This model contains extensions to the YANG language that topology and
inventory models will use to define and annotate types and relationships
Copyright (C) 2024 Ericsson
Modifications Copyright (C) 2024-2025 OpenInfra Foundation Europe
Licensed under the Apache License, Version 2.0 (the \"License\");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an \"AS IS\" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
SPDX-License-Identifier: Apache-2.0";
revision "2025-02-14" {
description "Updates for bi-directional relationship.";
or-teiv-yext:label 1.1.0;
reference "O-RAN.WG10.TE&IV-DM.0-R004-v02.00";
}
revision "2024-10-10" {
description "Initial revision.";
or-teiv-yext:label 1.0.0;
reference "O-RAN.WG10.TE&IV-DM.0-R004-v01.00";
}
extension biDirectionalTopologyRelationship {
argument relationshipName;
description
"Defines a bi-directional relationship in the topology.
A bi-directional-association (BDA) is a relationship comprising of
an aSide and a bSide. The aSide is considered the originating
side of the relationship; the bSide is considered the terminating
side of the relationship. The order of aSide and bSide is of
importance and MUST NOT be changed once defined.
Both aSide and bSide are defined on a type, and are given a role.
A type may have multiple originating and/or terminating sides of a
relationship, all distinguished by role name.
The statement MUST only be a substatement of the 'module' statement.
Multiple 'biDirectionalTopologyRelationship' statements are
allowed per parent statement.
Substatements to the 'biDirectionalTopologyRelationship' define
the aSide and the bSide, respectively, and optionally properties
of the relationship. Data nodes of types 'leaf' and 'leaf-list' are
used for this purpose. One of the data nodes MUST be annotated with
the 'aSide' extension; another data node MUST be annotated with the
'bSide' extension. Other data nodes define properties of the
relationship.
The argument is the name of the relationship. The relationship name
is scoped to the namespace of the declaring module and MUST be
unique within the scope.";
}
extension aSide {
argument aSideType;
description
"Defines the aSide of a relationship.
The statement MUST only be a substatement of a 'leaf' or 'leaf-list'
statement, which itself must be a substatement of the
'biDirectionalTopologyRelationship' statement.
The data type of the parent 'leaf' or 'leaf-list' MUST be
'instance-identifier'. Constraints MAY be used as part of the parent
'leaf' or 'leaf-list' to enforce cardinality.
The identifier of the parent 'leaf' or 'leaf-list' is used as name
of the role of the aSide of the relationship. The name of the role
is scoped to the type on which the aSide is defined and MUST be
unique within the scope.
While the parent 'leaf' or 'leaf-list' does not result in a property
of the relationship, it is RECOMMENDED to avoid using the name of an
existing type property as role name to avoid potential ambiguities
between properties of a type, and roles of a relationship on the type.
The argument is the name of the type on which the aSide resides.
If the type is declared in another module, the type must be
prefixed, and a corresponding 'import' statement be used to declare
the prefix.";
}
extension bSide {
argument bSideType;
description
"Defines the bSide of a relationship.
The statement MUST only be a substatement of a 'leaf' or 'leaf-list'
statement, which itself must be a substatement of the
'biDirectionalTopologyRelationship' statement.
The data type of the parent 'leaf' or 'leaf-list' MUST be
'instance-identifier'. Constraints MAY be used as part of the parent
'leaf' or 'leaf-list' to enforce cardinality.
The identifier of the parent 'leaf' or 'leaf-list' is used as name
of the role of the bSide of the relationship. The name of the role
is scoped to the type on which the bSide is defined and MUST be
unique within the scope.
While the parent 'leaf' or 'leaf-list' does not result in a property
of the relationship, it is RECOMMENDED to avoid using the name of an
existing type property as role name to avoid potential ambiguities
between properties of a type, and roles of a relationship on the type.
The argument is the name of the type on which the bSide resides.
If the type is declared in another module, the type must be
prefixed, and a corresponding 'import' statement be used to declare
the prefix.";
}
extension domain {
argument domainName;
description "Keyword used to carry domain information.";
}
extension label {
argument semversion;
description
"The label can be used to give modules and submodules a semantic
version, in addition to their revision.
The format of the label is 'x.y.z' - expressed as pattern, it is
[0-9]+\\.[0-9]+\\.[0-9]+
The statement MUST only be a substatement of the revision statement.
Zero or one revision label statements per parent statement are
allowed.
Revision labels MUST be unique amongst all revisions of a module or
submodule.";
}
}