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.

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

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

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

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;
         }
     }

   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>

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.

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

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

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.

   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.

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.

   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.

   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;
         }
     }

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

   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.

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

   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.

   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.

   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.

   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.