Impact of 'report-all-tagged' <with-defaults> mode on edit-config

NETCONF
1

Hi all,

I was going through RFC6243, section 4.5.2 to understand the Impact of ‘report-all-tagged’ mode on edit-config.

I could not get what RFC is talking about in below paragraph:
If the server supports the ‘report-all-tagged’ mode, then the ‘default’ attribute defined in Section 6 also impacts the operation. If the ‘default’ attribute is present and set to ‘true’ or ‘1’, then the server MUST treat the new data node as a request to return that node to its default value (i.e., remove it from the configuration datastore). The data node within the NETCONF message MUST contain a value in this case, which MUST be equal to the schema default value. If not, the server MUST return an response with an ‘invalid-value’ error-tag.

Can anyone explain what RFC is meaning here?

2

Let’s say your YANG model has:

leaf foo {
  type int32;
  default 42;
}

and the current value of this leaf is 17. Then an edit-config with

<foo>42</foo>

will set the value of this leaf to 42, whereas (for the ‘report-all-tagged’ mode), with

<foo default="true">42</foo>

the leaf will actually be deleted, making the default value of 42 come into effect, subject to the requirements in https://tools.ietf.org/html/rfc7950#section-7.6.1. I.e. there is a difference between a leaf having an explicitly set value that is the same as the default value, and the default value coming into effect due to no value having been set. (This distinction doesn’t really exist in “trim” mode.) And

<foo default="true">99</foo>

would be an error, since the default value isn’t 99.

Seems quite convoluted, you could of course just as well do

<foo nc:operation="delete"/>

for the return-to-default case - but the RFC needs to specify what should happen when you use the default attribute of ‘report-all-tagged’ mode, which is of course primarily meaningful for <get> and <get-config>, for <edit-config>.

3

Thanks a lot for the detailed explanation