On 10/16/2015 2:49 PM, Martin Bjorklund wrote:
Andy Bierman <a...@yumaworks.com> 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.

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?
No.

Or that it gets ignored and not enforced?
No.

IMO this section was rather clear -- it applies to when-stmt
in the RPC input.
No - and that's the problem which we need to fix.  It might be that we
all agree on the expected server behavior ,and if that's the case, we
just need to fix the text to align with what we meant.  In order to
resolve this, it would be very helpful if you could provide your
opinion on the questions in the three scenarios below:

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

I would expect 1).



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

I would expect 3)

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
I would expect 3)


In SNMP, when a set operation contains multiple variable bindings, the rule is:

"Each variable assignment specified by the SetRequest-PDU should be effected as if
simultaneously set with respect to all other assignments specified in
the same message."

I would expect the same rule applies for edit-config. That is , the order is not
significant.

-Xiang Li

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to