[netmod] IPR check draft-ietf-netmod-yang-data-ext-04

2019-09-26 Thread Joel Jaeggli 
Authors, Contributors, WG,

As part of WG Last Call for  draft-ietf-netmod-yang-data-ext-04

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty 
.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.

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

[netmod] WG Last Call: draft-ietf-netmod-yang-data-ext version 4

2019-09-26 Thread Joel Jaeggli 
All,

This starts a two week working group last call for  
draft-ietf-netmod-yang-data-ext-04

The working group last call ends on  Friday October 11th 2019.  Please send 
your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document and believe it is ready 
for publication", are welcome!  This is useful and important, even from authors.

https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-04 


The diff from 03, produced prior to IETF 105 is available here:

https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-netmod-yang-data-ext-04.txt
 


Thanks
Joel

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

[netmod] Upcoming important Dates leading to IETF 106

2019-09-26 Thread Joel Jaeggli 
Folks, 

It's worth noting that there are several important upcoming dates between the 
present and IETF 106 November 16-22 2019.


The early bird deadline for registration is this coming  Monday, September 30th.

October 18th is publication of the initial agenda

November 4th is Draft submission cutoff

November 6th the chairs have to publish the initial meeting agenda.

These are dates that we are going to be working towards and around for 
currently in the queue documents as well as new work.

Thanks
The NETMOD Chairs
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Andy Bierman 
On Thu, Sep 26, 2019 at 11:35 AM Schönwälder, Jürgen <
j.schoenwael...@jacobs-university.de> wrote:

> On Thu, Sep 26, 2019 at 10:44:01AM -0700, Andy Bierman wrote:
>
> > The IETF has completely punted the problem of converting data for a
> > configuration datastore to the schema tree for .
>
> I am not sure. The  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 , I can check
> /foo/bar in  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.
>
>

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.




> 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  or just ?
>
> 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  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.
>
> > 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).
>
> 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.
>
>
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


>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Schönwälder , Jürgen 
On Thu, Sep 26, 2019 at 10:44:01AM -0700, Andy Bierman wrote:

> The IETF has completely punted the problem of converting data for a
> configuration datastore to the schema tree for .

I am not sure. The  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 , I can check
/foo/bar in  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.
 
> 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  or just ?

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

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

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Andy Bierman 
Hi,


On Thu, Sep 26, 2019 at 9:14 AM tom petch  wrote:

> Inline
>
> Tom Petch
>
> - Original Message -
> From: "Andy Bierman" 
> To: "Rob Wilton (rwilton)" 
> Cc: ; 
> Sent: Thursday, September 26, 2019 3:33 PM
>
> On Thu, Sep 26, 2019 at 3:32 AM Rob Wilton (rwilton) 
> wrote:
>
> >
> >
> > > -Original Message-
> > > From: netmod  On Behalf Of Martin Bjorklund
> > > Sent: 26 September 2019 08:45
> > > To: lho...@nic.cz
> > > Cc: yang...@huawei.com; netmod@ietf.org
> > > Subject: Re: [netmod] 答复: 答复: Please clarify implementation about
> > > ‘when’
> > >
> > > > >
> > > > > It also says in 8.2:
> > > > >
> > > > >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.
> > > >
> > > > 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).
>
> 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).
>
> 
>
> 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.
>
>
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  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 . 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  or just ?
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).



> Tom Petch
>
>
Andy


> Thanks,
> > Rob
> >
> >
>
> Andy
>
>
> >
> > >
> > > /martin
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > ___
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] What's the problem with NMDA? was Re: 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread tom petch 
Inline

Tom Petch

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

On Thu, Sep 26, 2019 at 3:32 AM Rob Wilton (rwilton) 
wrote:

>
>
> > -Original Message-
> > From: netmod  On Behalf Of Martin Bjorklund
> > Sent: 26 September 2019 08:45
> > To: lho...@nic.cz
> > Cc: yang...@huawei.com; netmod@ietf.org
> > Subject: Re: [netmod] 答复: 答复: Please clarify implementation about
> > ‘when’
> >
> > > >
> > > > It also says in 8.2:
> > > >
> > > >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.
> > >
> > > 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).

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



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,
> Rob
>
>

Andy


>
> >
> > /martin
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> ___

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

Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Andy Bierman 
On Thu, Sep 26, 2019 at 3:32 AM Rob Wilton (rwilton) 
wrote:

>
>
> > -Original Message-
> > From: netmod  On Behalf Of Martin Bjorklund
> > Sent: 26 September 2019 08:45
> > To: lho...@nic.cz
> > Cc: yang...@huawei.com; netmod@ietf.org
> > Subject: Re: [netmod] 答复: 答复: Please clarify implementation about
> > ‘when’
> >
> > > >
> > > > It also says in 8.2:
> > > >
> > > >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.
> > >
> > > 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).
>
>
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,
> Rob
>
>

Andy


>
> >
> > /martin
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Ladislav Lhotka 
Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> On Thu, 2019-09-26 at 11:04 +, Schönwälder, Jürgen wrote:
>> > On Thu, Sep 26, 2019 at 12:27:17PM +0200, Ladislav Lhotka wrote:
>> > > > 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.
>> > > 
>> > > I do insist that the wording in 7950 permits my interpretation, so I 
>> > > don't
>> > > propose any change.
>> > 
>> > 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?
>
> 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=
>
>   tree with the "when" expression is deleted by the server.
>
> 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.
>

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

>
>
> /martin
>
>
>
>> 
>> > 
>> > > 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.
>> > 
>> > This is a different topic. Moving things around does not change the
>> > 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
>> 
>> > 
>> > /js
>> > 
>> > -- 
>> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> > Fax:   +49 421 200 3103 
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

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

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

Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Martin Bjorklund 
Ladislav Lhotka  wrote:
> On Thu, 2019-09-26 at 11:04 +, Schönwälder, Jürgen wrote:
> > On Thu, Sep 26, 2019 at 12:27:17PM +0200, Ladislav Lhotka wrote:
> > > > 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.
> > > 
> > > I do insist that the wording in 7950 permits my interpretation, so I don't
> > > propose any change.
> > 
> > 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?

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=

  tree with the "when" expression is deleted by the server.

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



> 
> > 
> > > 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.
> > 
> > This is a different topic. Moving things around does not change the
> > 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
> 
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Ladislav Lhotka 
On Thu, 2019-09-26 at 11:04 +, Schönwälder, Jürgen wrote:
> On Thu, Sep 26, 2019 at 12:27:17PM +0200, Ladislav Lhotka wrote:
> > > 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.
> > 
> > I do insist that the wording in 7950 permits my interpretation, so I don't
> > propose any change.
> 
> 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.

> 
> > 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.
> 
> This is a different topic. Moving things around does not change the
> 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

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Schönwälder , Jürgen 
On Thu, Sep 26, 2019 at 12:27:17PM +0200, Ladislav Lhotka wrote:
> > 
> > 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.
> 
> I do insist that the wording in 7950 permits my interpretation, so I don't
> propose any change.

It does not. You cannot cherry pick sentences.

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

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

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Rob Wilton (rwilton) 


> -Original Message-
> From: netmod  On Behalf Of Martin Bjorklund
> Sent: 26 September 2019 08:45
> To: lho...@nic.cz
> Cc: yang...@huawei.com; netmod@ietf.org
> Subject: Re: [netmod] 答复: 答复: Please clarify implementation about
> ‘when’
> 
> > >
> > > It also says in 8.2:
> > >
> > >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.
> >
> > 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


> 
> /martin
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Ladislav Lhotka 
On Thu, 2019-09-26 at 09:39 +, Schönwälder, Jürgen wrote:
> On Thu, Sep 26, 2019 at 09:45:26AM +0200, Martin Bjorklund wrote:
> > > > >o  There MUST be no nodes tagged with "when" present if the "when"
> > > > >   condition evaluates to "false" in the data tree.
> > > > 
> > > > It also says in 8.2:
> > > > 
> > > >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.
> > > 
> > > 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.
> > 
> 
> Yes, this auto-delete behaviour is part of the specification and it
> 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.

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

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

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Schönwälder , Jürgen 
On Thu, Sep 26, 2019 at 09:45:26AM +0200, Martin Bjorklund wrote:
> > > 
> > > >o  There MUST be no nodes tagged with "when" present if the "when"
> > > 
> > > >   condition evaluates to "false" in the data tree.
> > > 
> > > 
> > > It also says in 8.2:
> > > 
> > >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.
> > 
> > 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.
>

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 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Martin Bjorklund 
Ladislav Lhotka  wrote:
> On Thu, 2019-09-26 at 08:56 +0200, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > Andy Bierman  writes:
> > 
> > > 
> > 
> > > > On Wed, Sep 25, 2019 at 8:44 AM Sterne, Jason (Nokia - CA/Ottawa) <
> > 
> > > > jason.ste...@nokia.com> wrote:
> > 
> > > >
> > 
> > > >> 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.
> > 
> > > >>
> > 
> > > >>
> > 
> > > >>
> > 
> > > >
> > 
> > > > +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.
> > 
> > > 
> > 
> > > 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.
> > 
> > 
> > It also says in 8.2:
> > 
> >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.
> 
> 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.


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

Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Ladislav Lhotka 
On Thu, 2019-09-26 at 08:56 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > Andy Bierman  writes:
> 
> > 
> 
> > > On Wed, Sep 25, 2019 at 8:44 AM Sterne, Jason (Nokia - CA/Ottawa) <
> 
> > > jason.ste...@nokia.com> wrote:
> 
> > >
> 
> > >> 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.
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >
> 
> > > +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.
> 
> > 
> 
> > 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.
> 
> 
> It also says in 8.2:
> 
>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.

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
> 
> > >
> 
> > >
> 
> > >>
> 
> > >>
> 
> > >> *From:* netmod  *On Behalf Of *Qin Wu
> 
> > >> *Sent:* Tuesday, September 10, 2019 10:33 PM
> 
> > >> *To:* Fengchong (frank) ; Andy Bierman <
> 
> > >> a...@yumaworks.com>
> 
> > >> *Cc:* netmod@ietf.org; Yangang 
> 
> > >> *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:
> 
> > >>
> 
> > >> “
> 
> > >>
> 
> > >> 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  (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"  in the  during payload
> parsing phase and NETCONF 
> 
> > >>
> 
> > >> Processing until all validation complete, otherwise it seems server will
> 
> > >>
> 
> > >> Send multiple rply with "unknown-element"  in the 
> which seems not reasonable.
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >> -Qin
> 
> > >>
> 
> > >> *发件人**:* netmod [mailto:netmod-boun...@ietf.org 
> ]
> 
> > >> *代表 *Fengchong (frank)
> 
> > >> *发送时间**:* 2019年9月11日 9:29
> 
> > >> *收件人**:* Andy Bierman 
> 
> > >> *抄送**:* netmod@ietf.org; Yangang 
> 
> > >> *主题**:* [netmod] 答复: Please clarify implementation about ‘when’
> 
> > >>
> 
> > >>
> 
> > >>
> 
> > >> 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

Re: [netmod] evaluating 'when' statements with unconfigured leafs

2019-09-26 Thread Ladislav Lhotka 
"Sterne, Jason (Nokia - CA/Ottawa)"  writes:

> Hi all,
>
> I saw some recent questions about 'when' statements. I had another one 
> related to evaluating 'when' statements that involve leafs that don't 
> currently have a value at all.
>
> leaf foo {
> type enumeration {
> enum val1;
> enum val2;
> }
> }
>
> leaf bar {
> when "../foo != 'val2'";
> type uint8;
> }
>
> Notice that foo does not have a default statement. So if no manager has set 
> leaf foo, it doesn't exist in the config.
>
> In that case, does the "when" statement evaluate to 'true'  (i.e. leaf bar is 
> allowed to have a value) ?
>
> i.e. assuming leaf foo is not set at all, is this accepted?
> 23
>
> Or is there something special here because of the non-existence of leaf foo?
>
> If the "when" evaluates to 'false', then does the following "when" evaluate 
> differently than the one above?
> when "not(../foo = 'val2')";

Indeed it does. If the "foo" instance doesn't exist, then this expression 
evaluates to true.

Lada

>
> Jason
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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

Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Martin Bjorklund 
Ladislav Lhotka  wrote:
> Andy Bierman  writes:
> 
> > On Wed, Sep 25, 2019 at 8:44 AM Sterne, Jason (Nokia - CA/Ottawa) <
> > jason.ste...@nokia.com> wrote:
> >
> >> 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.
> >>
> >>
> >>
> >
> > +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.
> 
> 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.

It also says in 8.2:

   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.


/martin

> 
> This can also be prevented if the server rejects an edit operation
> that would create such a situation.
> 
> Lada
> 
> 
> >
> >
> >> Jason
> >>
> >
> > Andy
> >
> >
> >>
> >>
> >> *From:* netmod  *On Behalf Of *Qin Wu
> >> *Sent:* Tuesday, September 10, 2019 10:33 PM
> >> *To:* Fengchong (frank) ; Andy Bierman <
> >> a...@yumaworks.com>
> >> *Cc:* netmod@ietf.org; Yangang 
> >> *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:
> >>
> >> “
> >>
> >> 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  (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"  in the  during payload 
> >> parsing phase and NETCONF 
> >>
> >> Processing until all validation complete, otherwise it seems server will
> >>
> >> Send multiple rply with "unknown-element"  in the  
> >> which seems not reasonable.
> >>
> >>
> >>
> >> -Qin
> >>
> >> *发件人**:* netmod [mailto:netmod-boun...@ietf.org ]
> >> *代表 *Fengchong (frank)
> >> *发送时间**:* 2019年9月11日 9:29
> >> *收件人**:* Andy Bierman 
> >> *抄送**:* netmod@ietf.org; Yangang 
> >> *主题**:* [netmod] 答复: Please clarify implementation about ‘when’
> >>
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >>

Re: [netmod] 答复: 答复: Please clarify implementation about ‘when’

2019-09-26 Thread Ladislav Lhotka 
Andy Bierman  writes:

> On Wed, Sep 25, 2019 at 8:44 AM Sterne, Jason (Nokia - CA/Ottawa) <
> jason.ste...@nokia.com> wrote:
>
>> 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.
>>
>>
>>
>
> +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.

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


>
>
>> Jason
>>
>
> Andy
>
>
>>
>>
>> *From:* netmod  *On Behalf Of *Qin Wu
>> *Sent:* Tuesday, September 10, 2019 10:33 PM
>> *To:* Fengchong (frank) ; Andy Bierman <
>> a...@yumaworks.com>
>> *Cc:* netmod@ietf.org; Yangang 
>> *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:
>>
>> “
>>
>> 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  (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"  in the  during payload 
>> parsing phase and NETCONF 
>>
>> Processing until all validation complete, otherwise it seems server will
>>
>> Send multiple rply with "unknown-element"  in the  
>> which seems not reasonable.
>>
>>
>>
>> -Qin
>>
>> *发件人**:* netmod [mailto:netmod-boun...@ietf.org ]
>> *代表 *Fengchong (frank)
>> *发送时间**:* 2019年9月11日 9:29
>> *收件人**:* Andy Bierman 
>> *抄送**:* netmod@ietf.org; Yangang 
>> *主题**:* [netmod] 答复: Please clarify implementation about ‘when’
>>
>>
>>
>> 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.
>>
>>
>>
>>
>> --
>>
>> 华为技术有限公司 Huawei Technologies Co., Ltd.
>>
>> [image: Company_logo]
>>
>> 个人签名：冯冲
>> 手 机：13776612983
>> 电子邮件：frank.fengch...@huawei.com
>> 公司网址：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