say I have this
container c {
leaf l1;
leaf l2 (default 'abcd');
}
and I do this (restconf):
DELETE /c/l2
what is the expected behavior in the server ? is it
after issuing the delete , what is the expected result for a GET
GET /c
c {
l1 : 100 // for ex
l2 : 'abcd'
}
This is described in RFC7950, Section 7.6.1:
The default value of a leaf is the value that the server uses if the leaf does not exist in the data tree. The usage of the default value depends on the leaf's closest ancestor node in the schema tree that is not a non-presence container (see Section 7.5.1):
- If no such ancestor exists in the schema tree, the default value MUST be used.
- Otherwise, if this ancestor is a case node, the default value MUST be used if any node from the case exists in the data tree or the case node is the choice's default case, and if no nodes from any other case exist in the data tree.
- Otherwise, the default value MUST be used if the ancestor node exists in the data tree.
In these cases, the default value is said to be in use.
Note that if the leaf or any of its ancestors has a "when" condition or "if-feature" expression that evaluates to "false", then the default value is not in use.
When the default value is in use, the server MUST operationally behave as if the leaf was present in the data tree with the default value as its value.
If a leaf has a "default" statement, the leaf's default value is the value of the "default" statement. Otherwise, if the leaf's type has a default value and the leaf is not mandatory, then the leaf's default value is the type's default value. In all other cases, the leaf does not have a default value.
In your case c
is a non-presence container, therefore the first bullet above kicks in. This means your default will be in use if you delete the corresponding leaf from the data tree (yes, you can delete it). The server MUST therefore operationally behave as if the leaf was present, and this leaf must have the specified default value.
It does not matter which protocol is used to do the operations.
For RESTCONF and GET, the behavior is described in RFC8040, Section 3.5.4:
RESTCONF requires that a server report its default-handling mode (see Section 9.1.2 for details). If the optional "with-defaults" query parameter is supported by the server, a client may use it to control the retrieval of default values (see Section 4.8.9 for details).
If a leaf or leaf-list is missing from the configuration and there is a YANG-defined default for that data resource, then the server MUST use the YANG-defined default as the configured value.
If the target of a GET method is a data node that represents a leaf or leaf-list that has a default value and the leaf or leaf-list has not been instantiated yet, the server MUST return the default value or values that are in use by the server. In this case, the server MUST ignore its "basic-mode", described in Section 4.8.9, and return the default value.
If the target of a GET method is a data node that represents a container or list that has any child resources with default values, for the child resources that have not been given values yet, the server MAY return the default values that are in use by the server in accordance with its reported default-handling mode and query parameters passed by the client.
So your GET example may or may not be correct, depending on which defaults handling mode is in effect, as the last paragraph above suggests.