Hi,
Balazs Lengyel <balazs.leng...@ericsson.com> wrote:
> Hello Andy, Martin,
> If that is what is meant by 8.2.1 then I have a few comments
Sorry for the confusion on this topic. I have now done some digging
in the archives and I think that section 8.2 is really intended to
apply only to *configuration data* (which it actually says upfront).
The text in 8.2.1 is not intended to be for generic rpcs; it is
intended for rpcs that modify configuration datastores (edit-config).
The whole idea is that there are really three points in time where
"checks" are done - (1) simple type checks and structural checks when
the edit-config is parsed (2) check that the requested _operations_
are valid and (3) check that the _resulting datastore_ is valid.
This said, note that section 8.1 applies to *all* valid data trees,
including rpc/action input/output.
So, in summary, 8.1 defines the generic rules for valid data trees,
and 8.2 defines the NETCONF-specific behavior for edit-config
processing.
In order to resolve Balazs' original issue, we need to agree what
should happen in these cases *for NETCONF*.
Suppose we have:
leaf a {
when "../b = 42";
type int32;
}
leaf b {
type int32;
}
Scenario A
----------
The DB contains b=10
The server gets an edit-config with:
<a>2</a>
What is the result?
1) an error is returned
2) ok; the request to set a to 2 is silently dropped
Scenario B
----------
The DB contains b=10.
The server gets an edit-config with:
<a>2</a>
<b>42</b>
What is the result?
1) an error is returned
2) ok, db now has b=42; the request to set a to 2 is silently
dropped
3) ok, db now has a=2 and b=42
Scenario C (same as 2, but different order in edit-config)
----------
The DB contains b=10.
The server gets an edit-config with:
<b>42</b>
<a>2</a>
What is the result?
1) an error is returned
2) ok, db now has b=42; the request to set a to 2 is silently
dropped
3) ok, db now has a=2 and b=42
/martin
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
