Subject: [netmod] Please clarify implementation about ‘when’

From: "Fengchong (frank)" <[email-masked]>
Date: Fri, 6 Sep 2019 07:18:39 +0000

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?

---

From: "Fengchong (frank)" <[email-masked]>
Date: Mon, 9 Sep 2019 12:28:37 +0000

--------------------------------------------------
冯冲 Feng Chong
Mobile: +86-13776612983<tel:+86-13776612983>
Email: [email-masked]<mailto:[email-masked]>
发件人：Fengchong (frank) <[email-masked]>
收件人：netmod <[email-masked]>
抄 送：Yangang <[email-masked]>
时 间：2019-09-06 15:19:28
主题[netmod] Please clarify implementation about ‘when’

Hi all,

YANG module：
module foo {

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 9 Sep 2019 13:40:56 +0000

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-masked]> On Behalf Of Fengchong (frank)
Sent: 06 September 2019 08:19
To: [email-masked]
Cc: Yangang <[email-masked]>
Subject: [netmod] Please clarify implementation about ‘when’

Hi all,

YANG module：
module foo {

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Sep 2019 10:13:44 -0700

Hi,

None of the operations that accept or return datastore contents expose the
datastore objects
in the RPC parameters.  They are always anyxml or anydata. This means that
there are no descendant data nodes defined at all according to the RPC
operation
and therefore the constraints on those nodes do not exist in the RPC
operation either.

On Mon, Sep 9, 2019 at 6:41 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> 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 {
>
> *From:* netmod <[email-masked]> *On Behalf Of *Fengchong (frank)
> *Sent:* 06 September 2019 08:19
> *To:* [email-masked]
> *Cc:* Yangang <[email-masked]>
> *Subject:* [netmod] Please clarify implementation about ‘when’
>
>
>
> Hi all,
>
>
>
> In section 8.2 <https://tools.ietf.org/html/rfc7950#section-8.2>.
> Configuration Data Modifications
>
> In 8.3.1 <https://tools.ietf.org/html/rfc7950#section-8.3.1>.  Payload
> Parsing
>
> In 8.3.2 <https://tools.ietf.org/html/rfc7950#section-8.3.2>.  NETCONF
> <edit-config> Processing
>
> 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:
>
> 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.
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: "Fengchong (frank)" <[email-masked]>
Date: Tue, 10 Sep 2019 01:59:55 +0000

Hi rob,
Thank you for your kind interpretation.

It seems the text of RFC is not very clear. Whether in the payload parsing phase or the edit-config processing phase, the when condition will be  evaluated according to the results expected by the user.

________________________________
华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]
个人签名：冯冲
手　　机：13776612983
电子邮件：[email-masked]
公司网址：www.huawei.com
________________________________
 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

发件人: Rob Wilton (rwilton) [mailto:[email-masked]]
发送时间: 2019年9月9日 21:41
收件人: Fengchong (frank) <[email-masked]>; [email-masked]
抄送: Yangang <[email-masked]>
主题: RE: [netmod] Please clarify implementation about ‘when’

Hi Frank,

       rpc rock-the-house {
         input {
           leaf country {
             type string;
           }
           leaf zip-code {

Thanks,
Rob

From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Fengchong (frank)
Sent: 06 September 2019 08:19
To: [email-masked]<mailto:[email-masked]>
Cc: Yangang <[email-masked]<mailto:[email-masked]>>
Subject: [netmod] Please clarify implementation about ‘when’

Hi all,

YANG module：
module foo {

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

---

From: "Fengchong (frank)" <[email-masked]>
Date: Tue, 10 Sep 2019 02:09:56 +0000

Hi andy,

You only talk about the constraints on rpc operation’s parameter?

Do you have any opinion about my question?

发件人: Andy Bierman [mailto:[email-masked]]
发送时间: 2019年9月10日 1:14
收件人: Rob Wilton (rwilton) <[email-masked]>
抄送: Fengchong (frank) <[email-masked]>; [email-masked]; Yangang <[email-masked]>
主题: Re: [netmod] Please clarify implementation about ‘when’

Hi,

None of the operations that accept or return datastore contents expose the datastore objects
in the RPC parameters.  They are always anyxml or anydata. This means that
there are no descendant data nodes defined at all according to the RPC operation
and therefore the constraints on those nodes do not exist in the RPC operation either.

On Mon, Sep 9, 2019 at 6:41 AM Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Frank,

       rpc rock-the-house {
         input {
           leaf country {
             type string;
           }
           leaf zip-code {

Thanks,
Rob

Hi all,

YANG module：
module foo {

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Sep 2019 19:19:29 -0700

> Do you have any opinion about my question?

8.3.1 does not apply to leaf 'b'.
The RPC parameter is called 'config'.
It has no when-stmts to evaluate.
Rob is correct.
His example shows what 8.3.1 would cover.

Andy

>
> ------------------------------
>
> ------------------------------
>
> *发件人:* Andy Bierman [mailto:[email-masked]]
> *发送时间:* 2019年9月10日 1:14
> *收件人:* Rob Wilton (rwilton) <[email-masked]>
> *抄送:* Fengchong (frank) <[email-masked]>; [email-masked];
> Yangang <[email-masked]>
> *主题:* Re: [netmod] Please clarify implementation about ‘when’
>
>
>
> Hi,
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Sep 2019 19:39:57 -0700

Hi,

I see you are asking about when the server removes data nodes with false
when-stmts.
Our server would accept scene 1 and reject scene 2.
The when-stmts are evaluated against the desired datastore (same as leafref
validation)
after all the modifications are considered.

Andy

---

From: "Fengchong (frank)" <[email-masked]>
Date: Tue, 10 Sep 2019 02:40:19 +0000

Andy,
Whether all constraints on content in <config> parameter will not be evaluated in payload parsing phase, for example, a leaf’s value exceed range?
Netconf server should treat it as a block data?

Another question:

In edit-config processing phase, whether constraints on content in <config> parameter needs be evaluated?
If yes, when  configuration modification cause when condition is evaluated to false, the node tagged when will be automatically deleted by system.
Then, in scene 2, whether different result would occur according different process order?

发件人: Andy Bierman [mailto:[email-masked]]
发送时间: 2019年9月10日 10:19
收件人: Fengchong (frank) <[email-masked]>
抄送: Rob Wilton (rwilton) <[email-masked]>; [email-masked]; Yangang <[email-masked]>
主题: Re: [netmod] Please clarify implementation about ‘when’

On Mon, Sep 9, 2019 at 7:10 PM Fengchong (frank) <[email-masked]<mailto:[email-masked]>> wrote:
Hi andy,

Andy

电子邮件：[email-masked]<mailto:[email-masked]>
公司网址：www.huawei.com<http://www.huawei.com>

发件人: Andy Bierman [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2019年9月10日 1:14
收件人: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
抄送: Fengchong (frank) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Yangang <[email-masked]<mailto:[email-masked]>>
主题: Re: [netmod] Please clarify implementation about ‘when’

Hi,

       rpc rock-the-house {
         input {
           leaf country {
             type string;
           }
           leaf zip-code {

Thanks,
Rob

Hi all,

YANG module：
module foo {

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

---

From: "Fengchong (frank)" <[email-masked]>
Date: Tue, 10 Sep 2019 02:50:00 +0000

Andy,

Do you think when conditions should be evaluated during validation phase, for example when user issues validate operation or edit-config operation with ‘test-then-set’ test-option?

发送时间: 2019年9月10日 10:40

Hi,

I see you are asking about when the server removes data nodes with false when-stmts.
Our server would accept scene 1 and reject scene 2.
The when-stmts are evaluated against the desired datastore (same as leafref validation)
after all the modifications are considered.

Andy

Hi,

       rpc rock-the-house {
         input {
           leaf country {
             type string;
           }
           leaf zip-code {

Thanks,
Rob

Hi all,

YANG module：
module foo {

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Sep 2019 19:56:29 -0700

On Mon, Sep 9, 2019 at 7:40 PM Fengchong (frank) <[email-masked]>
wrote:

> Andy,
>
> Whether all constraints on content in <config> parameter will not be
> evaluated in payload parsing phase, for example, a leaf’s value exceed
> range?
>

Field validation and datastore validation are 2 different things.
when-stmt processing is neither. It is by far the hardest part of an
automated server to get right.

> If yes, when  configuration modification cause when condition is evaluated
> to false, the node tagged when will be automatically deleted by system.
>

Since the <config> parameter is anyxml, the YANG constraints defined on
datastore contents
are not enforced as part of RPC input validation.

It would be nice if NETCONF defined behavior for providing <config> data
that will get deleted
immediately by the server.  We have a CLI parameter for this since some
vendors want to
treat this as an error and other just silently delete nodes.  Note that
when-stmt can silently
delete existing nodes not included in the edit. (Lada does not agree this
is how it should work,
so we need yang-next to decide. Maybe NETCONF needs a --force parameter for
this purpose.)

Andy

> *发送时间:* 2019年9月10日 10:19
> *收件人:* Fengchong (frank) <[email-masked]>
> *抄送:* Rob Wilton (rwilton) <[email-masked]>; [email-masked]; Yangang <
> [email-masked]>
> On Mon, Sep 9, 2019 at 7:10 PM Fengchong (frank) <
> [email-masked]> wrote:
>
> Hi andy,
>
>
>

---

From: "Fengchong (frank)" <[email-masked]>
Date: Wed, 11 Sep 2019 01:28:54 +0000

Andy,

Whether different result would occur according different process order?
According 8.3.2
if server process ‘a= 3’ firstly, b will be deleted by system and becomes a non-exist schema node, and then  when ‘b=5’ is processed , server will report a ‘unknown-element’ error.
But if server process ‘b=5’ firstly, it will be accepted by server, and then when ‘a=3’ is processed, b will be deleted by system, but report OK.

If sec 8.3.2 is not right. What is the right?
When node a and node b in the same request, and b tagged when condition, a’s value will cause b’s condition is evaluated to false, which is more prior?
According you and Rob’s interpretation , maybe node ’a’ is more prior? If yes, why node ‘b’ should be processed later?

I think whether in edit-config processing phase the configuration tagged when should not be evaluated and be delayed to commit or validate?
When commit or validate operation is issued,  the data node tagged when will be evaluated, and if it’s evaluated to false, this data will be deleted by system immediately, server should not report any error.

发送时间: 2019年9月10日 10:56

On Mon, Sep 9, 2019 at 7:40 PM Fengchong (frank) <[email-masked]<mailto:[email-masked]>> wrote:
Andy,
Whether all constraints on content in <config> parameter will not be evaluated in payload parsing phase, for example, a leaf’s value exceed range?
Netconf server should treat it as a block data?

Field validation and datastore validation are 2 different things.
when-stmt processing is neither. It is by far the hardest part of an automated server to get right.

Another question:

Since the <config> parameter is anyxml, the YANG constraints defined on datastore contents
are not enforced as part of RPC input validation.

It would be nice if NETCONF defined behavior for providing <config> data that will get deleted
immediately by the server.  We have a CLI parameter for this since some vendors want to
treat this as an error and other just silently delete nodes.  Note that when-stmt can silently
delete existing nodes not included in the edit. (Lada does not agree this is how it should work,
so we need yang-next to decide. Maybe NETCONF needs a --force parameter for this purpose.)

Andy

发件人: Andy Bierman [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2019年9月10日 10:19
收件人: Fengchong (frank) <[email-masked]<mailto:[email-masked]>>
抄送: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Yangang <[email-masked]<mailto:[email-masked]>>
主题: Re: [netmod] Please clarify implementation about ‘when’

Andy

Hi,

       rpc rock-the-house {
         input {
           leaf country {
             type string;
           }
           leaf zip-code {

Thanks,
Rob

Hi all,

YANG module：
module foo {

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

---

From: Qin Wu <[email-masked]>
Date: Wed, 11 Sep 2019 02:33:06 +0000

Why processing order matter? My interpretation is both leaf node values (i.e.,leaf a, leaf b) should be validated together and commit as a whole,
RFC6241 said:
“
If the device is unable to commit all of the changes in the
         candidate configuration datastore, then the running
         configuration MUST remain unchanged.
”
So validate the leaf node value in the edit-config request (message content validation) is not important, validate the leaf node value that is applied to <running> (datastore validation) is the key.

I think what you want to raise is the server should hold on to send reply with an "unknown-element" <error-tag> in the <rpc-error> during payload parsing phase and NETCONF <edit-config>

Processing until all validation complete, otherwise it seems server will

Send multiple rply with "unknown-element" <error-tag> in the <rpc-error> which seems not reasonable.

-Qin
发件人: netmod [mailto:[email-masked]] 代表 Fengchong (frank)
发送时间: 2019年9月11日 9:29
收件人: Andy Bierman <[email-masked]>
抄送: [email-masked]; Yangang <[email-masked]>
主题: [netmod] 答复: Please clarify implementation about ‘when’

Andy,

Another question:

Andy

Andy

Hi,

       rpc rock-the-house {
         input {
           leaf country {
             type string;
           }
           leaf zip-code {

Thanks,
Rob

Hi all,

YANG module：
module foo {

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 25 Sep 2019 15:44:51 +0000

Processing order should not matter. The evaluation of the 'when' statement should be done assuming an atomic application of the edit-config.

I agree that a standards compliant server should do as Rob said:

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

From an implementation that may indeed mean processing the 'when' after a first pass that sets the various leafs to tentative values. But that's implementation detail.

IMO the auto-clearing behavior of 'when' may be complicated but that is how it is defined (same with 'choice'). Clients can and should depend on things being automatically deleted. If you want validation errors (i.e. force the client to clear all the dependant leafs instead of auto-clearing) then use a 'must' statement.

Jason

From: netmod <[email-masked]> On Behalf Of Qin Wu
Sent: Tuesday, September 10, 2019 10:33 PM
To: Fengchong (frank) <[email-masked]>; Andy Bierman <[email-masked]>
Cc: [email-masked]; Yangang <[email-masked]>
Subject: [netmod] 答复: 答复: Please clarify implementation about ‘when’

-Qin
发件人: netmod [mailto:[email-masked]] 代表 Fengchong (frank)
发送时间: 2019年9月11日 9:29
收件人: Andy Bierman <[email-masked]<mailto:[email-masked]>>
抄送: [email-masked]<mailto:[email-masked]>; Yangang <[email-masked]<mailto:[email-masked]>>
主题: [netmod] 答复: Please clarify implementation about ‘when’

Andy,

Another question:

Andy

Andy

Hi,

       rpc rock-the-house {
         input {
           leaf country {
             type string;
           }
           leaf zip-code {

Thanks,
Rob

Hi all,

YANG module：
module foo {

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Sep 2019 08:59:21 -0700

On Wed, Sep 25, 2019 at 8:44 AM Sterne, Jason (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> Processing order should not matter. The evaluation of the 'when' statement
> should be done assuming an atomic application of the edit-config.
>
>
>
> - For “scene 1”, the config change is accepted because the result of the
> - For “scene 2”, the config change is rejected because the result of the
> From an implementation that may indeed mean processing the 'when' after a
> first pass that sets the various leafs to tentative values. But that's
> implementation detail.
>
>
>
> IMO the auto-clearing behavior of 'when' may be complicated but that is
> how it is defined (same with 'choice'). Clients can and should depend on
> things being automatically deleted. If you want validation errors (i.e.
> force the client to clear all the dependant leafs instead of auto-clearing)
> then use a 'must' statement.
>
>
>

+1

YANG clearly defines "must" and "when" with different behavior.
A server that does not implement the auto-delete aspects of when-stmt is
not compliant to the RFC.

Andy

>
>
> *From:* netmod <[email-masked]> *On Behalf Of *Qin Wu
> *Sent:* Tuesday, September 10, 2019 10:33 PM
> *To:* Fengchong (frank) <[email-masked]>; Andy Bierman <
> [email-masked]>
> *Cc:* [email-masked]; Yangang <[email-masked]>
> *Subject:* [netmod] 答复: 答复: Please clarify implementation about ‘when’
>
>
>
> Why processing order matter? My interpretation is both leaf node values
> (i.e.,leaf a, leaf b) should be validated together and commit as a whole,
>
> RFC6241 said:
>
> “
>
> So validate the leaf node value in the edit-config request (message
> content validation) is not important, validate the leaf node value that is
> applied to <running> (datastore validation) is the key.
>
>
>
> *发件人**:* netmod [mailto:[email-masked] <[email-masked]>]
> *代表 *Fengchong (frank)
> *发送时间**:* 2019年9月11日 9:29
> *收件人**:* Andy Bierman <[email-masked]>
> *抄送**:* [email-masked]; Yangang <[email-masked]>
> *主题**:* [netmod] 答复: Please clarify implementation about ‘when’
>
>
>
> Andy,
>
>
>
> if server process ‘a= 3’ firstly, b will be deleted by system and becomes
> a non-exist schema node, and then  when ‘b=5’ is processed , server will
> report a ‘unknown-element’ error.
>
> But if server process ‘b=5’ firstly, it will be accepted by server, and
> then when ‘a=3’ is processed, b will be deleted by system, but report OK.
>
>
>
> When node a and node b in the same request, and b tagged when condition,
> a’s value will cause b’s condition is evaluated to false, which is more
> prior?
>
> According you and Rob’s interpretation , maybe node ’a’ is more prior? If
> yes, why node ‘b’ should be processed later?
>
>
>
> I think whether in edit-config processing phase the configuration tagged
> when should not be evaluated and be delayed to commit or validate?
>
> When commit or validate operation is issued,  the data node tagged when
> will be evaluated, and if it’s evaluated to false, this data will be
> deleted by system immediately, server should not report any error.
>
>
>
>
> *发件人**:* Andy Bierman [mailto:[email-masked] <[email-masked]>]
> *发送时间**:* 2019年9月10日 10:56
> *收件人**:* Fengchong (frank) <[email-masked]>
> *抄送**:* Rob Wilton (rwilton) <[email-masked]>; [email-masked];
> *主题**:* Re: [netmod] Please clarify implementation about ‘when’
>
>
>
>
>
>
>
> On Mon, Sep 9, 2019 at 7:40 PM Fengchong (frank) <
> *发件人**:* Andy Bierman [mailto:[email-masked]]
> *发送时间**:* 2019年9月10日 10:19
> *收件人**:* Fengchong (frank) <[email-masked]>
> *抄送**:* Rob Wilton (rwilton) <[email-masked]>; [email-masked];
> *主题**:* Re: [netmod] Please clarify implementation about ‘when’
>
>
>
>
>
>
>
> *发件人**:* Andy Bierman [mailto:[email-masked]]
> *发送时间**:* 2019年9月10日 1:14
> *收件人**:* Rob Wilton (rwilton) <[email-masked]>
> *抄送**:* Fengchong (frank) <[email-masked]>; [email-masked];
> *主题**:* Re: [netmod] Please clarify implementation about ‘when’
>
>
>
> Hi,
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Sep 2019 09:00:17 -0700

On Wed, Sep 25, 2019 at 8:59 AM Andy Bierman <[email-masked]> wrote:

>> Processing order should not matter. The evaluation of the 'when'
>> statement should be done assuming an atomic application of the edit-config.
>>
>>
>>

oops -- s/must-stmt/when-stmt/

>> If yes, when  configuration modification cause when condition is
>> evaluated to false, the node tagged when will be automatically deleted by
>> system.
>>
>> 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:
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>

---

From: Qin Wu <[email-masked]>
Date: Thu, 26 Sep 2019 02:54:45 +0000

发件人: Andy Bierman [mailto:[email-masked]]
发送时间: 2019年9月26日 0:00
收件人: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
抄送: Qin Wu <[email-masked]>; Fengchong (frank) <[email-masked]>; [email-masked]; Yangang <[email-masked]>
主题: Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

On Wed, Sep 25, 2019 at 8:59 AM Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Sep 25, 2019 at 8:44 AM Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
Processing order should not matter. The evaluation of the 'when' statement should be done assuming an atomic application of the edit-config.

[Qin]: Good clarification.

+1

YANG clearly defines "must" and "when" with different behavior.
A server that does not implement the auto-delete aspects of when-stmt is not compliant to the RFC.

[Qin]: implement the auto-delete aspects of must-stmt is a must for server or implement client force delete aspects of must stmt is a must for a server?
So for both  “scene 1” and “scene 2”, the client will not receive validation error unless when statement is replaced with must statement in the below example model?
I thought validation error will still be received when the config change is reject in “scene 2”.
Jason

Andy

From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Qin Wu
Sent: Tuesday, September 10, 2019 10:33 PM
To: Fengchong (frank) <[email-masked]<mailto:[email-masked]>>; Andy Bierman <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Yangang <[email-masked]<mailto:[email-masked]>>
Subject: [netmod] 答复: 答复: Please clarify implementation about ‘when’

-Qin

Andy,

Another question:

Andy

Andy

Hi,

       rpc rock-the-house {
         input {
           leaf country {
             type string;
           }
           leaf zip-code {

Thanks,
Rob

Hi all,

YANG module：
module foo {

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

The second request:
<edit-config>
   <target>
      <candidate/>
   </target>
   <config>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Sep 2019 20:57:23 -0700

On Wed, Sep 25, 2019 at 7:54 PM Qin Wu <[email-masked]> wrote:

> *发送时间:* 2019年9月26日 0:00
> *收件人:* Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
> *抄送:* Qin Wu <[email-masked]>; Fengchong (frank) <
> [email-masked]>; [email-masked]; Yangang <[email-masked]>
> *主题:* Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’
>
>
>
>
>
>
>
> [Qin]: implement the auto-delete aspects of must-stmt is a must for server
> or implement client force delete aspects of must stmt is a must for a
> server?
>
> So for both  “scene 1” and “scene 2”, the client will not receive
> validation error unless when statement is replaced with must statement in
> the below example model?
>

sorry for the confusion. it was right the first time.
when-stmt has auto-delete.
must-stmt has error instead of auto-delete.

 Andy

Jason

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Sep 2019 08:49:43 +0200

> not compliant to the RFC.

I don't agree with this. RFC 7950 says in sec. 8.1:

   The following properties are true in all data trees:

   ...

   o  There MUST be no nodes tagged with "when" present if the "when"
      condition evaluates to "false" in the data tree.

This can also be prevented if the server rejects an edit operation that would create such a situation.

Lada

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 26 Sep 2019 08:56:44 +0200 (CEST)

>       condition evaluates to "false" in the data tree.

It also says in 8.2:

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Sep 2019 09:08:56 +0200

On Thu, 2019-09-26 at 08:56 +0200, Martin Bjorklund wrote:
> statement

Right. But the request won't modify a configuration data node because it is
rejected. So the premise of the above implication doesn't hold, and the
conclusion doesn't apply.

Lada 

> 
> 
> /martin
> 
> > 
> 
> > This can also be prevented if the server rejects an edit operation
> 
> > that would create such a situation.
> 
> > 
> 
> > Lada
> 
> > 
> 
> > 
> 
> > >
> 
> > >
> 
> > >> Jason
> 
> > >>
> 
> > >
> 
> > > Andy
> 
> > >
> 
> > >
> 
> > >>
> 
> > >>
> 
> > >> I think what you want to raise is the server should hold on to send reply
> with an "unknown-element" <error-tag> in the <rpc-error> during payload
> parsing phase and NETCONF <edit-config>
> 
> > >>
> 
> > >> This e-mail and its attachments contain confidential information from
> 
> > >> HUAWEI, which
> 
> > >> is intended only for the person or entity whose address is listed above.
> 
> > >> Any use of the
> 
> > >> information contained herein in any way (including, but not limited to,
> 
> > >> total or partial
> 
> > >> disclosure, reproduction, or dissemination) by persons other than the
> 
> > >> intended
> 
> > >> recipient(s) is prohibited. If you receive this e-mail in error, please
> 
> > >> notify the sender by
> 
> > >> In edit-config processing phase, whether constraints on content in
> 
> > >> <config> parameter needs be evaluated?
> 
> > >>
> 
> evaluated
> > >> Then, in scene 2, whether different result would occur according
> different
> 
> > >> process order?
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >> so we need yang-next to decide. Maybe NETCONF needs a --force parameter
> 
> > >> for this purpose.)
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >> Andy
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >> This e-mail and its attachments contain confidential information from
> 
> > >> HUAWEI, which
> 
> > >> is intended only for the person or entity whose address is listed above.
> 
> > >> Any use of the
> 
> > >> information contained herein in any way (including, but not limited to,
> 
> > >> total or partial
> 
> > >> disclosure, reproduction, or dissemination) by persons other than the
> 
> > >> intended
> 
> > >> recipient(s) is prohibited. If you receive this e-mail in error, please
> 
> > >> notify the sender by
> 
> > >> This e-mail and its attachments contain confidential information from
> 
> > >> HUAWEI, which
> 
> > >> is intended only for the person or entity whose address is listed above.
> 
> > >> Any use of the
> 
> > >> information contained herein in any way (including, but not limited to,
> 
> > >> total or partial
> 
> > >> disclosure, reproduction, or dissemination) by persons other than the
> 
> > >> intended
> 
> > >> recipient(s) is prohibited. If you receive this e-mail in error, please
> 
> > >> notify the sender by
> 
> > >> In section 8.2 <https://tools.ietf.org/html/rfc7950#section-8.2>;.
> 
> > >> In 8.3.1 <https://tools.ietf.org/html/rfc7950#section-8.3.1>;.  Payload
> 
> > >> Parsing
> 
> > >>
> 
> > >> In 8.3.2 <https://tools.ietf.org/html/rfc7950#section-8.3.2>;.  NETCONF
> 
> > >> <edit-config> Processing
> 
> > >>
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 26 Sep 2019 09:45:26 +0200 (CEST)

> conclusion doesn't apply.

With the same logic you can claim conformance if you reject a request
to create nodes under a case if another case is active.  I think it is
quite clear that this auto-deletion is part of the spec, and something
clients can rely on.  If the intention had been that this was optional
to implement, it would have been clearly stated, and there would have
been mechanism present for clients to detect this.

/martin

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Thu, 26 Sep 2019 09:39:51 +0000

> been mechanism present for clients to detect this.

Yes, this auto-delete behaviour is part of the specification and it
was not an oversight that this slipped in.

Sure, one can discuss whether this feature is useful or harmful
but the only way to officially remove this is to create a new
specification and to run it through the IETF process.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Sep 2019 12:27:17 +0200

> was not an oversight that this slipped in.

Of course I know it was the intention, even though I have been against it all
the time.

> specification and to run it through the IETF process.

I do insist that the wording in 7950 permits my interpretation, so I don't
propose any change.

What I propose instead is to remove such protocol-specific parts from the
specification of the YANG language, and clarify it in the specification of
individual protocols.

Lada

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 26 Sep 2019 10:31:39 +0000

> -----Original Message-----
> From: netmod <[email-masked]> On Behalf Of Martin Bjorklund
> Sent: 26 September 2019 08:45
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netmod] 答复: 答复: Please clarify implementation about
> ‘when’
> 
> > >
> > > It also says in 8.2:
> > >
> > Right. But the request won't modify a configuration data node because
> > it is rejected. So the premise of the above implication doesn't hold,
> > and the conclusion doesn't apply.
> 
> With the same logic you can claim conformance if you reject a request to
> create nodes under a case if another case is active.  I think it is quite
> clear that this auto-deletion is part of the spec, and something clients
> can rely on.  If the intention had been that this was optional to
> implement, it would have been clearly stated, and there would have been
> mechanism present for clients to detect this.
> 
I don't like the 'when' behaviour, I would have rather that clients were forced to delete the configuration explicitly (or pass an option for an implicit delete).

However, I do agree with Martin & Juergen, that the intent of the spec is that servers perform the 'when' auto-delete behaviour, and clients must be able to rely on compliant servers behaving this way.

Thanks,
Rob

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Thu, 26 Sep 2019 11:04:36 +0000

> I do insist that the wording in 7950 permits my interpretation, so I don't

It does not. You cannot cherry pick sentences.

> specification of the YANG language, and clarify it in the specification of

This is a different topic. Moving things around does not change the
meaning (unless you change things as well while moving things around).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Sep 2019 13:29:52 +0200

> It does not. You cannot cherry pick sentences.

I am not aware of any cherry-picking on my side. Can you show that my
interpretation is not possible? Whatever the intent was, it is the text of the
spec that counts.

> meaning (unless you change things as well while moving things around).

I wrote about clarification of protocols or server behaviour, which means
changes. It is also possible that different protocols use different approaches.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 26 Sep 2019 14:11:46 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> interpretation is not possible?

8.2 says:

   o  If a request modifies a configuration data node such that any
      node's "when" expression becomes false, then the node in the data=

This means that requests can modify config this way, otherwise this
text wouldn't be there.  This is not just an intention, but follows
from the text.

>  Whatever the intent was, it is the text of the
> spec that counts.

With this logic, no client can be certain of anything; a server would
be free to reject legal requests in any way it liked.  For example it
would be perfectly fine for a server to only accept requests that
modifies a single leaf at the time.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 26 Sep 2019 15:43:34 +0200

> modifies a single leaf at the time.

This is quite different. If a client tries to violate e.g. the "pattern" property, the request is rejected. So there is a reason for the server to do the same for the other items in the same list of properties that have to be true in all trees.

Again, I think the biggest problem is that YANG spec attempts to "hardcode" this (and other) protocol behaviour. Different protocols and different deployments clearly need different approaches, and I think we have to live with it. Our (NETMOD) priority should IMO be to make YANG as widely usable as possible, and enforcing arbitrary protocol policies certainly doesn't help.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 Sep 2019 07:33:18 -0700

On Thu, Sep 26, 2019 at 3:32 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> I don't like the 'when' behaviour, I would have rather that clients were
> forced to delete the configuration explicitly (or pass an option for an
> implicit delete).
>
>
I hear the opposite from customers.
They insist that the server implement every last detail of the
machine-readable YANG,
especially when-stmt auto-deletion. The auto-cleanup is seen as a feature.

> However, I do agree with Martin & Juergen, that the intent of the spec is
> that servers perform the 'when' auto-delete behaviour, and clients must be
> able to rely on compliant servers behaving this way.
>
>
agreed.
It is hard to argue against consistent, predicable server behavior
for datastore editing.  (NP containers and NMDA are also causing problems,
and should be fixed in yang-next if that ever happens).

Thanks,

Andy

---

From: tom petch <[email-masked]>
Date: Thu, 26 Sep 2019 16:14:45 +0000

Inline

Tom Petch

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Rob Wilton (rwilton)" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, September 26, 2019 3:33 PM

On Thu, Sep 26, 2019 at 3:32 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> > > >       node's "when" expression becomes false, then the node in
the
> > data

I hear the opposite from customers.
They insist that the server implement every last detail of the
machine-readable YANG,
especially when-stmt auto-deletion. The auto-cleanup is seen as a
feature.

agreed.
It is hard to argue against consistent, predicable server behavior
for datastore editing.  (NP containers and NMDA are also causing
problems,
and should be fixed in yang-next if that ever happens).

<tp>

Andy

This caught my eye.  What is the problem with NMDA? Anything specific?

My own problem is that it is different to what has been proposed as
suitable for the previous 12 years but I doubt if many customers would
think that.

Tom Petch

Thanks,

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 Sep 2019 10:44:01 -0700

Hi,

> suitable for the previous 12 years but I doubt if many customers would
My comments are in the context of operator expectations for consistent
implementations.

The first problem with NMDA is the new YANG library.
There is an assumption that the client can and will change from an
architecture
where there is 1 schema tree per server to an architecture where there can
be a completely
different schema tree for configuration vs operational datastores.  There
is no such desire
or willingness on the client side to properly address this complexity. IMO
NMDA is going to
need to function without this complexity. The benefits of <operational> are
not hindered
at all (in a properly implemented server) if /yang-library is left out.

The IETF has completely punted the problem of converting data for a
configuration datastore
to the schema tree for <operational>. Deviations may be different.  A leaf
may
be string in 1 tree and decimal64 in the other. There is an incorrect
assumption
that software developers will deal with these corner-cases (correctly and
consistently).

The other big problem is an untested NMDA transition strategy that is not
well understood by vendors.
Should non-NMDA (/foo-state) be visible to <get-data> or just <get>?
Using the YANG library to separate the modules relies on the assumption that
the client is capable of managing each datastore independently (instead of
1 schema tree per server).

Andy

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Thu, 26 Sep 2019 18:35:14 +0000

On Thu, Sep 26, 2019 at 10:44:01AM -0700, Andy Bierman wrote:

> configuration datastore to the schema tree for <operational>.

I am not sure. The <operational> model consists of the applied
configuration plus any config false extras. NMDA simplifies things
since there is now a single tree structure instead of two if you have
to handle models where applied configuration can be different than
intended config. If I configure /foo/bar in <running>, I can check
/foo/bar in <operational> whether it exists and matches what I
configured.

> Deviations may be different.  A leaf may be string in 1 tree and
> decimal64 in the other. There is an incorrect assumption that
> software developers will deal with these corner-cases (correctly and
> consistently).

Not really true for applied config. And with non NMDA, there is no
guarantee either that /foo/bar and /foo-state/bar use the same type
and semantics.
 
> Should non-NMDA (/foo-state) be visible to <get-data> or just <get>?

Perhaps there is more explanation necessary. The idea here is that an
NMDA client should not bother to search for /foo-state, it should send
a <get> for /foo/state in operational.

Yes, NMDA requires updates to clients. Whether these are visible or in
which form they are visible to application logic likely depends on the
client design. But yes, NMDA is not for free for clients. But once you
have updated, we believe NMDA actually makes things simpler and more
consistent.

> 1 schema tree per server).

Yes, YANG library can express pretty complex server model
organizations.  This does not mean that all server have to use server
model organizations.  I assume that also many clients will not be
interested to understand the entire server model, they likely want to
check the existance of only those pieces that they care about.

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 Sep 2019 20:42:26 -0700

> guarantee either that /foo/bar and /foo-state/bar use the same type

different deviation modules in each module-set are allowed in the YANG
library.
That makes it kind of mandatory for the client to support it, or choose to
not conform to the standard.

> check the existance of only those pieces that they care about.
I am not trying to revive debates on the value of NMDA or the solution,
but more flexibility for the server means more complexity for the client.
IMO this is contributing to the slow adoption of NMDA.

I hope the industry will find a transition solution (NMDA Lite) that fully
supports
the protocol operations, but uses the same module-set(s) in the YANG library
for all datastores.  If this is the expected norm for servers then clients
that support it
will work.  (I would like to hear about even one NMDA implementation
that supports complex YANG libraries).

/js

Andy

---

From: tom petch <[email-masked]>
Date: Fri, 27 Sep 2019 10:06:08 +0000

Andy

Thanks for the explanation - makes sense to me.

Tom Petch

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "tom petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 26, 2019 6:44 PM

Hi,

On Thu, Sep 26, 2019 at 9:14 AM tom petch <[email-masked]> wrote:

> > > > >    o  If a request modifies a configuration data node such
that
> any
> > > create nodes under a case if another case is active.  I think it
is
> quite
> > However, I do agree with Martin & Juergen, that the intent of the
spec
> is

The first problem with NMDA is the new YANG library.
There is an assumption that the client can and will change from an
architecture
where there is 1 schema tree per server to an architecture where there
can
be a completely
different schema tree for configuration vs operational datastores.
There
is no such desire
or willingness on the client side to properly address this complexity.
IMO
NMDA is going to
need to function without this complexity. The benefits of <operational>
are
not hindered
at all (in a properly implemented server) if /yang-library is left out.

The IETF has completely punted the problem of converting data for a
configuration datastore
to the schema tree for <operational>. Deviations may be different.  A
leaf
may
be string in 1 tree and decimal64 in the other. There is an incorrect
assumption
that software developers will deal with these corner-cases (correctly
and
consistently).

The other big problem is an untested NMDA transition strategy that is
not
well understood by vendors.
Should non-NMDA (/foo-state) be visible to <get-data> or just <get>?
Using the YANG library to separate the modules relies on the assumption
that
the client is capable of managing each datastore independently (instead
of
1 schema tree per server).

Andy

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 27 Sep 2019 10:40:00 +0000

Hi,

> From: netmod <[email-masked]> On Behalf Of Schönwälder, Jürgen
> Sent: 26 September 2019 19:35
> To: Andy Bierman <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复:
> Please clarify implementation about ‘when’
> 
> configuration plus any config false extras. NMDA simplifies things since
> there is now a single tree structure instead of two if you have to handle
> models where applied configuration can be different than intended config.
> If I configure /foo/bar in <running>, I can check /foo/bar in
> <operational> whether it exists and matches what I configured.
> 
> > decimal64 in the other. There is an incorrect assumption that software
> > developers will deal with these corner-cases (correctly and
> > consistently).
> 
> guarantee either that /foo/bar and /foo-state/bar use the same type and
> semantics.

Indeed.  For non-NMDA, even if /foo/bar and /foo-state/bar are the same type in the published model, there is no guarantee that a server won't deviate the /foo-state/bar leaf to change its type to differ from /foo/bar, and this is allowed.

But NMDA is aiming to be better than this.  One of the fundamental aims is that the config and operational values should be comparable, on the same relative datastore path and have the same type.

That is why RFC 8342 does not allow a server to change the type of a data node in operational, they are only allowed to remove it to indicate that it is not supported.

RFC 8342, section 5.3 The Operational State Datastore(operational):

   The datastore schema for <operational> MUST be a superset of the
   combined datastore schema used in all configuration datastores,
   except that configuration data nodes supported in a configuration
   datastore MAY be omitted from <operational> if a server is not able
   to accurately report them.

The intention here is:
 - If a server does a deviate "add|replace|delete" deviation on a config data node then that same deviation MUST be applied to all datastores that contain that data node in their schema (or otherwise operational cannot be a superset).
 - A server MAY have operational datastore specific deviate "not-supported" deviations.  The purpose of this is meant to help migration, ideally servers would not have these deviations.

Hence, a client/server can construct a single "superset" schema for the device, and then the schema for each individual datastore must be a subset of that "superset" schema (with the added requirement that there is only a single schema for all conventional datastores).

I appreciate that the new YANG library structurally allows invalid schemas to be defined, but then so does the old YANG library as well.  E.g. there is nothing in the old YANG library structure to prevent a server from reporting that it implements two different revisions of the same YANG 1.1 module.

Thanks,
Rob

> > not well understood by vendors.
> Perhaps there is more explanation necessary. The idea here is that an NMDA
> client should not bother to search for /foo-state, it should send a <get>
> for /foo/state in operational.
> 
> > Using the YANG library to separate the modules relies on the
> > assumption that the client is capable of managing each datastore
> > independently (instead of
> Yes, YANG library can express pretty complex server model organizations.
> This does not mean that all server have to use server model organizations.
> I assume that also many clients will not be interested to understand the
> entire server model, they likely want to check the existance of only those
> pieces that they care about.
> 
> /js
> 
> --

---

From: Andy Bierman <[email-masked]>
Date: Fri, 27 Sep 2019 09:30:29 -0700

On Fri, Sep 27, 2019 at 3:40 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> Indeed.  For non-NMDA, even if /foo/bar and /foo-state/bar are the same
> type in the published model, there is no guarantee that a server won't
> deviate the /foo-state/bar leaf to change its type to differ from /foo/bar,
> and this is allowed.
>
> But NMDA is aiming to be better than this.  One of the fundamental aims is
> that the config and operational values should be comparable, on the same
> relative datastore path and have the same type.
>
> That is why RFC 8342 does not allow a server to change the type of a data
> node in operational, they are only allowed to remove it to indicate that it
> is not supported.
>
>  - If a server does a deviate "add|replace|delete" deviation on a config
> data node then that same deviation MUST be applied to all datastores that
> contain that data node in their schema (or otherwise operational cannot be
> a superset).
>  - A server MAY have operational datastore specific deviate
> "not-supported" deviations.  The purpose of this is meant to help
> migration, ideally servers would not have these deviations.
>
> Hence, a client/server can construct a single "superset" schema for the
> device, and then the schema for each individual datastore must be a subset
> of that "superset" schema (with the added requirement that there is only a
> single schema for all conventional datastores).
>
>
IMO the new YANG library is the most disruptive and complex way possible to
express
a simple capability "operational value for configuration object foo
supported or not".
I prefer the capabilities module approach in
https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-04
Deprecating the YANG library and starting over is kind of a
bull-in-the-china-shop
approach to advertising some server capabilities.

I appreciate that the new YANG library structurally allows invalid schemas
> to be defined, but then so does the old YANG library as well.  E.g. there
> is nothing in the old YANG library structure to prevent a server from
> reporting that it implements two different revisions of the same YANG 1.1
> module.
>
> Thanks,
> Rob
>
>

Andy

> NMDA