Hi Frank,
My interpretation of what the expected behaviour is as follows.
For “scene 1”, the config change is accepted because the result of the config
datastore after the edit-config has been applied is valid.
For “scene 2”, the config change is rejected because the result of the config
datastore after the edit-config has been applied is invalid.
My interpretation is that the block of text in 8.3.1 payload parsing is primary
intended to refer to RFC input. E.g. if the RPC was defined something like
below, then the ‘when’ rule in 8.3.1 would enforce that a zip-code can only be
provided if the country is the USA.
rpc rock-the-house {
input {
leaf country {
type string;
}
leaf zip-code {
when “../country = ‘usa’”;
type string;
}
}
}
Thanks,
Rob
From: netmod <[email protected]> On Behalf Of Fengchong (frank)
Sent: 06 September 2019 08:19
To: [email protected]
Cc: Yangang <[email protected]>
Subject: [netmod] Please clarify implementation about ‘when’
Hi all,
In RFC7950 secton 8, several description about when：
In section 8.2<https://tools.ietf.org/html/rfc7950#section-8.2>. Configuration
Data Modifications
o If a request modifies a configuration data node such that any
node's "when" expression becomes false, then the node in the data
tree with the "when" expression is deleted by the server.
In 8.3.1<https://tools.ietf.org/html/rfc7950#section-8.3.1>. Payload Parsing
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>.
In 8.3.2<https://tools.ietf.org/html/rfc7950#section-8.3.2>. NETCONF
<edit-config> Processing
Modification requests for nodes tagged with "when", and the "when"
condition evaluates to "false". In this case, the server MUST
reply with an "unknown-element" <error-tag> in the <rpc-error>.
YANG module：
module foo {
namespace “http://foo.com”;
prefix “foo”;
Leaf a {…}
Leaf b {
When “a = 10”;
}
}
Scene 1:
The first edit-config request:
<edit-config>
<target>
<candidate/>
</target>
<config>
<a xmlns= “http://foo.com”>3</a>
</config>
</edit-config>
This request will set a = 3.
The second request:
<edit-config>
<target>
<candidate/>
</target>
<config>
<a xmlns= “http://foo.com”>10</a>
<b xmlns= “http://foo.com”>5</b>
</config>
</edit-config>
According 8.3.1, in rpc payload parsing phase, the a’s value in candidate
datastore is 3,so leaf b’s when condition is evaluated to false, server will
report ‘unknown-element’ error..
Is it expected by user?
Scene 2:
The first edit-config request:
<edit-config>
<target>
<candidate/>
</target>
<config>
<a xmlns= “http://foo.com”>10</a>
</config>
</edit-config>
This request will set a = 10.
The second request:
<edit-config>
<target>
<candidate/>
</target>
<config>
<a xmlns= “http://foo.com”>3</a>
<b xmlns= “http://foo.com”>5</b>
</config>
</edit-config>
According 8.3.1, in rpc payload parsing phase, the a’s value in candidate
datastore is 10, so leaf b’s when condition is evaluated to true, server will
accept this request in payload parsing phase.
In edit-config request processing phase, if leaf a’s modification is processed
firstly, the a’s value will be changed to 3, so the b’s when condition will be
false, when server process b’s modification, b will be treated as
unknown-element, the edit-config request will fail.
If leaf b’s modification is processed firstly, server will accept this
modification ,because b’s when condition is true, and when server process a’s
modification , this modification will be accepted, and b’s when condition will
be evaluated to false, leaf b will be deleted automatically, the edit-config
request will be OK.
How server should process this situation?
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
