> On 16 Oct 2015, at 17:03, Andy Bierman <[email protected]> wrote:
>
> Hi,
>
> I find all this fretting over when-stmt corner-cases to be a waste of time.
> I certainly have no intention of spending 100s of hours coding for
> corner-cases
> that have no operational value whatsoever. When-stmt has always been full
> of problems that exist on paper but not in real servers.
This may well be because YANG module authors so far have been aware of the
pitfalls of "when". Now that YANG is mushrooming all around, it may change very
soon.
Lada
>
> There is no need for the YANG spec to point out that the constraints
> only apply to YANG. That is self-evident.
>
> Why doesn't when-stmt apply to a plain rpc?
>
>
> rpc plot-point {
> input {
> leaf 3d {
> type boolean;
> default false;
> }
> leaf X { type uint32; }
> leaf Y { type uint32; }
> leaf Z {
> when "../3d";
> type uint32;
> }
> }
> }
>
>
> Are you saying that the when-stmt for Z is not allowed?
> Or that it gets ignored and not enforced?
> IMO this section was rather clear -- it applies to when-stmt
> in the RPC input.
>
>
> Andy
>
>
> On Fri, Oct 16, 2015 at 5:01 AM, Martin Bjorklund <[email protected]> wrote:
> Hi,
>
> Balazs Lengyel <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
