Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6020

YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)

Pages: 173
Proposed Standard
Errata
Part 5 of 7 – Pages 91 to 111
First   Prev   Next

Top   ToC   RFC6020 - Page 91   prevText

7.14. The notification Statement

The "notification" statement is used to define a NETCONF notification. It takes one argument, which is an identifier, followed by a block of substatements that holds detailed notification information. The "notification" statement defines a notification node in the schema tree. If a leaf in the notification tree has a "mandatory" statement with the value "true", the leaf MUST be present in a NETCONF notification. If a leaf in the notification tree has a default value, the NETCONF client MUST use this value in the same cases as described in Section 7.6.1. In these cases, the client MUST operationally behave as if the leaf was present in the NETCONF notification with the default value as its value.
Top   ToC   RFC6020 - Page 92
   If a "config" statement is present for any node in the notification
   tree, the "config" statement is ignored.

7.14.1. The notification's Substatements

+--------------+---------+-------------+ | substatement | section | cardinality | +--------------+---------+-------------+ | anyxml | 7.10 | 0..n | | choice | 7.9 | 0..n | | container | 7.5 | 0..n | | description | 7.19.3 | 0..1 | | grouping | 7.11 | 0..n | | if-feature | 7.18.2 | 0..n | | leaf | 7.6 | 0..n | | leaf-list | 7.7 | 0..n | | list | 7.8 | 0..n | | reference | 7.19.4 | 0..1 | | status | 7.19.2 | 0..1 | | typedef | 7.3 | 0..n | | uses | 7.12 | 0..n | +--------------+---------+-------------+

7.14.2. XML Mapping Rules

A notification node is encoded as a child XML element to the <notification> element defined in NETCONF Event Notifications [RFC5277]. The element's local name is the notification's identifier, and its namespace is the module's XML namespace (see Section 7.1.3).
Top   ToC   RFC6020 - Page 93

7.14.3. Usage Example

The following example defines a notification: module event { namespace "http://example.com/event"; prefix "ev"; notification event { leaf event-class { type string; } anyxml reporting-entity; leaf severity { type string; } } } A corresponding XML instance example of the complete notification: <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventTime>2008-07-08T00:01:00Z</eventTime> <event xmlns="http://example.com/event"> <event-class>fault</event-class> <reporting-entity> <card>Ethernet0</card> </reporting-entity> <severity>major</severity> </event> </notification>

7.15. The augment Statement

The "augment" statement allows a module or submodule to add to the schema tree defined in an external module, or the current module and its submodules, and to add to the nodes from a grouping in a "uses" statement. The argument is a string that identifies a node in the schema tree. This node is called the augment's target node. The target node MUST be either a container, list, choice, case, input, output, or notification node. It is augmented with the nodes defined in the substatements that follow the "augment" statement. The argument string is a schema node identifier (see Section 6.5). If the "augment" statement is on the top level in a module or submodule, the absolute form (defined by the rule
Top   ToC   RFC6020 - Page 94
   "absolute-schema-nodeid" in Section 12) of a schema node identifier
   MUST be used.  If the "augment" statement is a substatement to the
   "uses" statement, the descendant form (defined by the rule
   "descendant-schema-nodeid" in Section 12) MUST be used.

   If the target node is a container, list, case, input, output, or
   notification node, the "container", "leaf", "list", "leaf-list",
   "uses", and "choice" statements can be used within the "augment"
   statement.

   If the target node is a choice node, the "case" statement, or a case
   shorthand statement (see Section 7.9.2) can be used within the
   "augment" statement.

   If the target node is in another module, then nodes added by the
   augmentation MUST NOT be mandatory nodes (see Section 3.1).

   The "augment" statement MUST NOT add multiple nodes with the same
   name from the same module to the target node.

7.15.1. The augment's Substatements

+--------------+---------+-------------+ | substatement | section | cardinality | +--------------+---------+-------------+ | anyxml | 7.10 | 0..n | | case | 7.9.2 | 0..n | | choice | 7.9 | 0..n | | container | 7.5 | 0..n | | description | 7.19.3 | 0..1 | | if-feature | 7.18.2 | 0..n | | leaf | 7.6 | 0..n | | leaf-list | 7.7 | 0..n | | list | 7.8 | 0..n | | reference | 7.19.4 | 0..1 | | status | 7.19.2 | 0..1 | | uses | 7.12 | 0..n | | when | 7.19.5 | 0..1 | +--------------+---------+-------------+

7.15.2. XML Mapping Rules

All data nodes defined in the "augment" statement are defined as XML elements in the XML namespace of the module where the "augment" is specified. When a node is augmented, the augmenting child nodes are encoded as subelements to the augmented node, in any order.
Top   ToC   RFC6020 - Page 95

7.15.3. Usage Example

In namespace http://example.com/schema/interfaces, we have: container interfaces { list ifEntry { key "ifIndex"; leaf ifIndex { type uint32; } leaf ifDescr { type string; } leaf ifType { type iana:IfType; } leaf ifMtu { type int32; } } } Then, in namespace http://example.com/schema/ds0, we have: import interface-module { prefix "if"; } augment "/if:interfaces/if:ifEntry" { when "if:ifType='ds0'"; leaf ds0ChannelNumber { type ChannelNumber; } }
Top   ToC   RFC6020 - Page 96
   A corresponding XML instance example:

     <interfaces xmlns="http://example.com/schema/interfaces"
                 xmlns:ds0="http://example.com/schema/ds0">
       <ifEntry>
         <ifIndex>1</ifIndex>
         <ifDescr>Flintstone Inc Ethernet A562</ifDescr>
         <ifType>ethernetCsmacd</ifType>
         <ifMtu>1500</ifMtu>
       </ifEntry>
       <ifEntry>
         <ifIndex>2</ifIndex>
         <ifDescr>Flintstone Inc DS0</ifDescr>
         <ifType>ds0</ifType>
         <ds0:ds0ChannelNumber>1</ds0:ds0ChannelNumber>
       </ifEntry>
     </interfaces>

   As another example, suppose we have the choice defined in
   Section 7.9.7.  The following construct can be used to extend the
   protocol definition:

     augment /ex:system/ex:protocol/ex:name {
         case c {
             leaf smtp {
                 type empty;
             }
         }
     }

   A corresponding XML instance example:

     <ex:system>
       <ex:protocol>
         <ex:tcp/>
       </ex:protocol>
     </ex:system>

   or

     <ex:system>
       <ex:protocol>
         <other:smtp/>
       </ex:protocol>
     </ex:system>
Top   ToC   RFC6020 - Page 97

7.16. The identity Statement

The "identity" statement is used to define a new globally unique, abstract, and untyped identity. Its only purpose is to denote its name, semantics, and existence. An identity can either be defined from scratch or derived from a base identity. The identity's argument is an identifier that is the name of the identity. It is followed by a block of substatements that holds detailed identity information. The built-in datatype "identityref" (see Section 9.10) can be used to reference identities within a data model.

7.16.1. The identity's Substatements

+--------------+---------+-------------+ | substatement | section | cardinality | +--------------+---------+-------------+ | base | 7.16.2 | 0..1 | | description | 7.19.3 | 0..1 | | reference | 7.19.4 | 0..1 | | status | 7.19.2 | 0..1 | +--------------+---------+-------------+

7.16.2. The base Statement

The "base" statement, which is optional, takes as an argument a string that is the name of an existing identity, from which the new identity is derived. If no "base" statement is present, the identity is defined from scratch. If a prefix is present on the base name, it refers to an identity defined in the module that was imported with that prefix, or the local module if the prefix matches the local module's prefix. Otherwise, an identity with the matching name MUST be defined in the current module or an included submodule. Since submodules cannot include the parent module, any identities in the module that need to be exposed to submodules MUST be defined in a submodule. Submodules can then include this submodule to find the definition of the identity. An identity MUST NOT reference itself, neither directly nor indirectly through a chain of other identities.
Top   ToC   RFC6020 - Page 98

7.16.3. Usage Example

module crypto-base { namespace "http://example.com/crypto-base"; prefix "crypto"; identity crypto-alg { description "Base identity from which all crypto algorithms are derived."; } } module des { namespace "http://example.com/des"; prefix "des"; import "crypto-base" { prefix "crypto"; } identity des { base "crypto:crypto-alg"; description "DES crypto algorithm"; } identity des3 { base "crypto:crypto-alg"; description "Triple DES crypto algorithm"; } }

7.17. The extension Statement

The "extension" statement allows the definition of new statements within the YANG language. This new statement definition can be imported and used by other modules. The statement's argument is an identifier that is the new keyword for the extension and must be followed by a block of substatements that holds detailed extension information. The purpose of the "extension" statement is to define a keyword, so that it can be imported and used by other modules. The extension can be used like a normal YANG statement, with the statement name followed by an argument if one is defined by the extension, and an optional block of substatements. The statement's name is created by combining the prefix of the module in which the
Top   ToC   RFC6020 - Page 99
   extension was defined, a colon (":"), and the extension's keyword,
   with no interleaving whitespace.  The substatements of an extension
   are defined by the extension, using some mechanism outside the scope
   of this specification.  Syntactically, the substatements MUST be YANG
   statements, or also defined using "extension" statements.  YANG
   statements in extensions MUST follow the syntactical rules in
   Section 12.

7.17.1. The extension's Substatements

+--------------+---------+-------------+ | substatement | section | cardinality | +--------------+---------+-------------+ | argument | 7.17.2 | 0..1 | | description | 7.19.3 | 0..1 | | reference | 7.19.4 | 0..1 | | status | 7.19.2 | 0..1 | +--------------+---------+-------------+

7.17.2. The argument Statement

The "argument" statement, which is optional, takes as an argument a string that is the name of the argument to the keyword. If no argument statement is present, the keyword expects no argument when it is used. The argument's name is used in the YIN mapping, where it is used as an XML attribute or element name, depending on the argument's "yin- element" statement.
7.17.2.1. The argument's Substatements
+--------------+----------+-------------+ | substatement | section | cardinality | +--------------+----------+-------------+ | yin-element | 7.17.2.2 | 0..1 | +--------------+----------+-------------+
7.17.2.2. The yin-element Statement
The "yin-element" statement, which is optional, takes as an argument the string "true" or "false". This statement indicates if the argument is mapped to an XML element in YIN or to an XML attribute (see Section 11). If no "yin-element" statement is present, it defaults to "false".
Top   ToC   RFC6020 - Page 100

7.17.3. Usage Example

To define an extension: module my-extensions { ... extension c-define { description "Takes as argument a name string. Makes the code generator use the given name in the #define."; argument "name"; } } To use the extension: module my-interfaces { ... import my-extensions { prefix "myext"; } ... container interfaces { ... myext:c-define "MY_INTERFACES"; } }

7.18. Conformance-Related Statements

This section defines statements related to conformance, as described in Section 5.6.

7.18.1. The feature Statement

The "feature" statement is used to define a mechanism by which portions of the schema are marked as conditional. A feature name is defined that can later be referenced using the "if-feature" statement (see Section 7.18.2). Schema nodes tagged with a feature are ignored by the device unless the device supports the given feature. This allows portions of the YANG module to be conditional based on conditions on the device. The model can represent the abilities of the device within the model, giving a richer model that allows for differing device abilities and roles.
Top   ToC   RFC6020 - Page 101
   The argument to the "feature" statement is the name of the new
   feature, and follows the rules for identifiers in Section 6.2.  This
   name is used by the "if-feature" statement to tie the schema nodes to
   the feature.

   In this example, a feature called "local-storage" represents the
   ability for a device to store syslog messages on local storage of
   some sort.  This feature is used to make the "local-storage-limit"
   leaf conditional on the presence of some sort of local storage.  If
   the device does not report that it supports this feature, the
   "local-storage-limit" node is not supported.

     module syslog {
         ...
         feature local-storage {
             description
                 "This feature means the device supports local
                  storage (memory, flash or disk) that can be used to
                  store syslog messages.";
         }

         container syslog {
             leaf local-storage-limit {
                 if-feature local-storage;
                 type uint64;
                 units "kilobyte";
                 config false;
                 description
                     "The amount of local storage that can be
                      used to hold syslog messages.";
             }
         }
     }

   The "if-feature" statement can be used in many places within the YANG
   syntax.  Definitions tagged with "if-feature" are ignored when the
   device does not support that feature.

   A feature MUST NOT reference itself, neither directly nor indirectly
   through a chain of other features.

   In order for a device to implement a feature that is dependent on any
   other features (i.e., the feature has one or more "if-feature" sub-
   statements), the device MUST also implement all the dependant
   features.
Top   ToC   RFC6020 - Page 102
7.18.1.1. The feature's Substatements
+--------------+---------+-------------+ | substatement | section | cardinality | +--------------+---------+-------------+ | description | 7.19.3 | 0..1 | | if-feature | 7.18.2 | 0..n | | status | 7.19.2 | 0..1 | | reference | 7.19.4 | 0..1 | +--------------+---------+-------------+

7.18.2. The if-feature Statement

The "if-feature" statement makes its parent statement conditional. The argument is the name of a feature, as defined by a "feature" statement. The parent statement is implemented by servers that support this feature. If a prefix is present on the feature name, it refers to a feature defined in the module that was imported with that prefix, or the local module if the prefix matches the local module's prefix. Otherwise, a feature with the matching name MUST be defined in the current module or an included submodule. Since submodules cannot include the parent module, any features in the module that need to be exposed to submodules MUST be defined in a submodule. Submodules can then include this submodule to find the definition of the feature.

7.18.3. The deviation Statement

The "deviation" statement defines a hierarchy of a module that the device does not implement faithfully. The argument is a string that identifies the node in the schema tree where a deviation from the module occurs. This node is called the deviation's target node. The contents of the "deviation" statement give details about the deviation. The argument string is an absolute schema node identifier (see Section 6.5). Deviations define the way a device or class of devices deviate from a standard. This means that deviations MUST never be part of a published standard, since they are the mechanism for learning how implementations vary from the standards.
Top   ToC   RFC6020 - Page 103
   Device deviations are strongly discouraged and MUST only be used as a
   last resort.  Telling the application how a device fails to follow a
   standard is no substitute for implementing the standard correctly.  A
   device that deviates from a module is not fully compliant with the
   module.

   However, in some cases, a particular device may not have the hardware
   or software ability to support parts of a standard module.  When this
   occurs, the device makes a choice either to treat attempts to
   configure unsupported parts of the module as an error that is
   reported back to the unsuspecting application or ignore those
   incoming requests.  Neither choice is acceptable.

   Instead, YANG allows devices to document portions of a base module
   that are not supported or supported but with different syntax, by
   using the "deviation" statement.

7.18.3.1. The deviation's Substatements
+--------------+----------+-------------+ | substatement | section | cardinality | +--------------+----------+-------------+ | description | 7.19.3 | 0..1 | | deviate | 7.18.3.2 | 1..n | | reference | 7.19.4 | 0..1 | +--------------+----------+-------------+
7.18.3.2. The deviate Statement
The "deviate" statement defines how the device's implementation of the target node deviates from its original definition. The argument is one of the strings "not-supported", "add", "replace", or "delete". The argument "not-supported" indicates that the target node is not implemented by this device. The argument "add" adds properties to the target node. The properties to add are identified by substatements to the "deviate" statement. If a property can only appear once, the property MUST NOT exist in the target node. The argument "replace" replaces properties of the target node. The properties to replace are identified by substatements to the "deviate" statement. The properties to replace MUST exist in the target node.
Top   ToC   RFC6020 - Page 104
   The argument "delete" deletes properties from the target node.  The
   properties to delete are identified by substatements to the "delete"
   statement.  The substatement's keyword MUST match a corresponding
   keyword in the target node, and the argument's string MUST be equal
   to the corresponding keyword's argument string in the target node.

                       The deviates's Substatements

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | config       | 7.19.1  | 0..1        |
                 | default      | 7.6.4   | 0..1        |
                 | mandatory    | 7.6.5   | 0..1        |
                 | max-elements | 7.7.4   | 0..1        |
                 | min-elements | 7.7.3   | 0..1        |
                 | must         | 7.5.3   | 0..n        |
                 | type         | 7.4     | 0..1        |
                 | unique       | 7.8.3   | 0..n        |
                 | units        | 7.3.3   | 0..1        |
                 +--------------+---------+-------------+

7.18.3.3. Usage Example
In this example, the device is informing client applications that it does not support the "daytime" service in the style of RFC 867. deviation /base:system/base:daytime { deviate not-supported; } The following example sets a device-specific default value to a leaf that does not have a default value defined: deviation /base:system/base:user/base:type { deviate add { default "admin"; // new users are 'admin' by default } } In this example, the device limits the number of name servers to 3: deviation /base:system/base:name-server { deviate replace { max-elements 3; } }
Top   ToC   RFC6020 - Page 105
   If the original definition is:

     container system {
         must "daytime or time";
         ...
     }

   a device might remove this must constraint by doing:

     deviation "/base:system" {
         deviate delete {
             must "daytime or time";
         }
     }

7.19. Common Statements

This section defines substatements common to several other statements.

7.19.1. The config Statement

The "config" statement takes as an argument the string "true" or "false". If "config" is "true", the definition represents configuration. Data nodes representing configuration will be part of the reply to a <get-config> request, and can be sent in a <copy-config> or <edit-config> request. If "config" is "false", the definition represents state data. Data nodes representing state data will be part of the reply to a <get>, but not to a <get-config> request, and cannot be sent in a <copy-config> or <edit-config> request. If "config" is not specified, the default is the same as the parent schema node's "config" value. If the parent node is a "case" node, the value is the same as the "case" node's parent "choice" node. If the top node does not specify a "config" statement, the default is "true". If a node has "config" set to "false", no node underneath it can have "config" set to "true".

7.19.2. The status Statement

The "status" statement takes as an argument one of the strings "current", "deprecated", or "obsolete".
Top   ToC   RFC6020 - Page 106
   o  "current" means that the definition is current and valid.

   o  "deprecated" indicates an obsolete definition, but it permits new/
      continued implementation in order to foster interoperability with
      older/existing implementations.

   o  "obsolete" means the definition is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations.

   If no status is specified, the default is "current".

   If a definition is "current", it MUST NOT reference a "deprecated" or
   "obsolete" definition within the same module.

   If a definition is "deprecated", it MUST NOT reference an "obsolete"
   definition within the same module.

   For example, the following is illegal:

     typedef my-type {
       status deprecated;
       type int32;
     }

     leaf my-leaf {
       status current;
       type my-type; // illegal, since my-type is deprecated
     }

7.19.3. The description Statement

The "description" statement takes as an argument a string that contains a human-readable textual description of this definition. The text is provided in a language (or languages) chosen by the module developer; for the sake of interoperability, it is RECOMMENDED to choose a language that is widely understood among the community of network administrators who will use the module.

7.19.4. The reference Statement

The "reference" statement takes as an argument a string that is used to specify a textual cross-reference to an external document, either another module that defines related management information, or a document that provides additional information relevant to this definition.
Top   ToC   RFC6020 - Page 107
   For example, a typedef for a "uri" data type could look like:

     typedef uri {
       type string;
       reference
         "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax";
       ...
     }

7.19.5. The when Statement

The "when" statement makes its parent data definition statement conditional. The node defined by the parent data definition statement is only valid when the condition specified by the "when" statement is satisfied. The statement's argument is an XPath expression (see Section 6.4), which is used to formally specify this condition. If the XPath expression conceptually evaluates to "true" for a particular instance, then the node defined by the parent data definition statement is valid; otherwise, it is not. See Section 8.3.2 for additional information. The XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1: o If the "when" statement is a child of an "augment" statement, then the context node is the augment's target node in the data tree, if the target node is a data node. Otherwise, the context node is the closest ancestor node to the target node that is also a data node. o If the "when" statement is a child of a "uses", "choice", or "case" statement, then the context node is the closest ancestor node to the "uses", "choice", or "case" node that is also a data node. o If the "when" statement is a child of any other data definition statement, the context node is the data definition's node in the data tree. o The accessible tree is made up of all nodes in the data tree, and all leafs with default values in use (see Section 7.6.1).
Top   ToC   RFC6020 - Page 108
   The accessible tree depends on the context node:

   o  If the context node represents configuration, the tree is the data
      in the NETCONF datastore where the context node exists.  The XPath
      root node has all top-level configuration data nodes in all
      modules as children.

   o  If the context node represents state data, the tree is all state
      data on the device, and the <running/> datastore.  The XPath root
      node has all top-level data nodes in all modules as children.

   o  If the context node represents notification content, the tree is
      the notification XML instance document.  The XPath root node has
      the element representing the notification being defined as the
      only child.

   o  If the context node represents RPC input parameters, the tree is
      the RPC XML instance document.  The XPath root node has the
      element representing the RPC operation being defined as the only
      child.

   o  If the context node represents RPC output parameters, the tree is
      the RPC reply instance document.  The XPath root node has the
      elements representing the RPC output parameters as children.

   The result of the XPath expression is converted to a boolean value
   using the standard XPath rules.

   Note that the XPath expression is conceptually evaluated.  This means
   that an implementation does not have to use an XPath evaluator on the
   device.  The "when" statement can very well be implemented with
   specially written code.

8. Constraints

8.1. Constraints on Data

Several YANG statements define constraints on valid data. These constraints are enforced in different ways, depending on what type of data the statement defines. o If the constraint is defined on configuration data, it MUST be true in a valid configuration data tree. o If the constraint is defined on state data, it MUST be true in a reply to a <get> operation without a filter.
Top   ToC   RFC6020 - Page 109
   o  If the constraint is defined on notification content, it MUST be
      true in any notification instance.

   o  If the constraint is defined on RPC input parameters, it MUST be
      true in an invocation of the RPC operation.

   o  If the constraint is defined on RPC output parameters, it MUST be
      true in the RPC reply.

8.2. Hierarchy of Constraints

Conditions on parent nodes affect constraints on child nodes as a natural consequence of the hierarchy of nodes. "must", "mandatory", "min-elements", and "max-elements" constraints are not enforced if the parent node has a "when" or "if-feature" property that is not satisfied on the current device. In this example, the "mandatory" constraint on the "longitude" leaf are not enforced on devices that lack the "has-gps" feature: container location { if-feature has-gps; leaf longitude { mandatory true; ... } }

8.3. Constraint Enforcement Model

For configuration data, there are three windows when constraints MUST be enforced: o during parsing of RPC payloads o during processing of NETCONF operations o during validation Each of these scenarios is considered in the following sections.

8.3.1. Payload Parsing

When content arrives in RPC payloads, it MUST be well-formed XML, following the hierarchy and content rules defined by the set of models the device implements.
Top   ToC   RFC6020 - Page 110
   o  If a leaf data value does not match the type constraints for the
      leaf, including those defined in the type's "range", "length", and
      "pattern" properties, the server MUST reply with an
      "invalid-value" error-tag in the rpc-error, and with the error-
      app-tag and error-message associated with the constraint, if any
      exist.

   o  If all keys of a list entry are not present, the server MUST reply
      with a "missing-element" error-tag in the rpc-error.

   o  If data for more than one case branch of a choice is present, the
      server MUST reply with a "bad-element" in the rpc-error.

   o  If data for a node tagged with "if-feature" is present, and the
      feature is not supported by the device, the server MUST reply with
      an "unknown-element" error-tag in the rpc-error.

   o  If data for a node tagged with "when" is present, and the "when"
      condition evaluates to "false", the server MUST reply with an
      "unknown-element" error-tag in the rpc-error.

   o  For insert handling, if the value for the attributes "before" and
      "after" are not valid for the type of the appropriate key leafs,
      the server MUST reply with a "bad-attribute" error-tag in the rpc-
      error.

   o  If the attributes "before" and "after" appears in any element that
      is not a list whose "ordered-by" property is "user", the server
      MUST reply with an "unknown-attribute" error-tag in the rpc-error.

8.3.2. NETCONF <edit-config> Processing

After the incoming data is parsed, the NETCONF server performs the <edit-config> operation by applying the data to the configuration datastore. During this processing, the following errors MUST be detected: o Delete requests for non-existent data. o Create requests for existent data. o Insert requests with "before" or "after" parameters that do not exist.
Top   ToC   RFC6020 - Page 111
   During <edit-config> processing:

   o  If the NETCONF operation creates data nodes under a "choice", any
      existing nodes from other "case" branches are deleted by the
      server.

   o  If the NETCONF operation modifies a data node such that any node's
      "when" expression becomes false, then the node with the "when"
      expression is deleted by the server.

8.3.3. Validation

When datastore processing is complete, the final contents MUST obey all validation constraints. This validation processing is performed at differing times according to the datastore. If the datastore is <running/> or <startup/>, these constraints MUST be enforced at the end of the <edit-config> or <copy-config> operation. If the datastore is <candidate/>, the constraint enforcement is delayed until a <commit> or <validate> operation. o Any "must" constraints MUST evaluate to "true". o Any referential integrity constraints defined via the "path" statement MUST be satisfied. o Any "unique" constraints on lists MUST be satisfied. o The "min-elements" and "max-elements" constraints are enforced for lists and leaf-lists.


(page 111 continued on part 6)

Next Section