Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

From: Balazs Lengyel <[email-masked]>
Date: Mon, 1 Aug 2016 10:55:37 +0200

Hello,

As I see it:

- The main problem is we don't agree whether or when NP
containers exist. Some people think they should exist (or not)
just as any other data node. (me, Andy, RFC6241) while others
believe the existence of the NP containers  is not even a valid
question (tailf). As we have such basic differences, I propose to
focus just on the specific protocol cases that are problematic.

- IMHO this problem means that the following 3 cases are not
properly defined and we need to clarify them. Saying the client
should just not use major parts of the protocol for NP-containers
is wrong.

1) what happens if default-operation=none meets a non-existing NP
container

2) what happens if you create an NP-container and that already
exists e.g. you issue create twice

3) what happens if you delete an NP-container that does not exists
e.g. issue the delete twice

IMHO saying that from the 6 operation values 3 are undefined for
NP-container is not acceptable.

As we have protocol operations defined in RC6020 we need to define
them properly.

regards Balazs

On 2016-08-01 02:23, Andy Bierman
wrote:

On Sun, Jul 31, 2016 at 10:45 AM,
Mahesh Jethanandani <[email-masked]>
wrote:

On Jul 30, 2016, at 5:31 PM, Andy Bierman <[email-masked]>
wrote:

On Sat, Jul 30, 2016 at
5:21 PM, Mahesh Jethanandani <[email-masked]>
wrote:

Andy,

The thread started because the RFC
does not say anything about a create of
a NP container. It only talked about
delete. Can we make the (re-)create of
the NP container unconditional to
whether a delete was performed on it. So
a tweak to your proposal would be:

The only reason that example did not work
is because the server deleted the NP
containers

after the client created them.  If the
server does not delete the containers then

the 2nd RPC will not fail.

I think this argument of whether server should or should
not create/delete NP containers is distracting from the
main point of when NP containers should exist. In my
mind, the NP container existence depends on whether
child nodes exist or not. In the end, if child nodes
exist, NP containers should exist (created), if they do
not exist, the NP container should be removed.

Can we agree on that?

No.

"should be removed" is an implementation choice.

It started as MAY be removed.  It needs to stay that
way.

As I have pointed out 100 times,  the protocol has
merge and replace

for the situation where the client is not exactly aware
of how ceration and

deletion will be handled on the server.

There is no reason to force implementations to change.

If you magically delete containers, then magically
recreate them.

If you don't then the nodes will be as the client
expects, so no problem.

Andy

P.s The errata will be much easier to craft if we
can agree on this.

This can also be completely avoided by
using the default (merge).

Since the client has to explicitly pick
default-operation=none,

it better know what it is doing.

This is the same issue as a default
leaf

and the create operation.  Nothing
special about NP containers.

The <edit-config> for "create"
will fail if the leaf already exists

and the "delete" will fail if the
value is not there (just a default).

The work-around?  Use merge and
remove, not create and delete.

IMO the same logic applies here.

Andy

OLD:

If a container does not have
a "presence" statement and the
last

child node is deleted, the
NETCONF server MAY delete the
container.

NEW:

If a container does not
have a "presence" statement and
the container instance

does not have any child
node instances, the NETCONF
server MAY delete the

container. It MUST create
the container instance if a
client <edit-config>
request

attempts to create a child
node instance within this
container.

On Jul 30, 2016, at 11:52
AM, Andy Bierman <[email-masked]>
wrote:

Hi,

I strongly object to
changing a vague MAY about
deleting an NP container

after the last child
has been deleted into
several MUST requirements.

I propose this text
instead:

OLD:

If a container
does not have a
"presence" statement and
the last

child node is
deleted, the NETCONF
server MAY delete the
container.

NEW:

If a container
does not have a
"presence" statement
and the container
instance

does not have
any child node
instances, the NETCONF
server MAY delete the

container. If
the server does delete
a container instance
in this case, it MUST

re-create the
container instance if a
client
<edit-config>
request attempts to
create

a child node
instance within this
container.

Andy

On
Fri, Jul 22, 2016 at
3:13 AM, Balazs
Lengyel <[email-masked]>
wrote:

Hello,

We seem to have
fundamental
differences
whether
NP-containers
exist/don't
exist or if this
question is even
valid.  I hope
we can agree
that as
NP-containers
are meaningless
themselves they
MUST NOT
influence
Netconf
operations or
model
validation.
(Which is a
slight violation
of Netconf-6241,
which we should
accept.)

So I propose
the following
errata to
rfc6020bis.

As for
non-presence
containers the
presence of the
container node
with no child
nodes is

semantically
equivalent to
the absence of
the container
node,
configuration
operations or

model validation
should never
fail due to the
existence or
non-existence of
a non-presence
containers.
Specifically:

- an
<edit-config>
create operation
for a
non-presence
container MUST
succeed even if
the container
already exists.

- an
<edit-config>
delete operation
for a
non-presence
container MUST
succeed even if
the container
does not exist.

- an
<edit-config>
operation with
default-operation=none
MUST succeed
even if one or
more
non-presence
containers do
not exist.

Separately

- a must
statement
defined as
direct
substatement of
a non-presence
container SHALL
be evaluated as
part of model
validation if
and only if one
or more child
data nodes exist
in the instance
data or if there
is a leaf or
leaf-list child
with a default
value. As
non-presence
containers are
only used for
organizing the
hierarchy they
SHOULD NOT have
any must
substatements.

IMO the above
rules remove
ambiguity and
follow the current
philosophy of
RFC6020bis.

If we have a basic
agreement I can
formulate the text
correctly.

I don't know
whether similar
updates are needed
for RestConf.

regards Balazs

PS. I still
believe
introducing NP
containers was a
mistake, however
they are here to
stay.

On 2016-07-21
09:17, Jan
Lindblad wrote:

Xiang,

Are
you saying
that since a
NP-container
is merely a
structure
node, not
config in any
way, so
creating/deleting
it explicitly
(and
repeatedly) is
equivalent to
a “no-op” that
will always
succeed
because doing
so has no
effect on the
server’s
config in any
way?

That's
correct.
"Creating" an
object with
zero bits of
information is
a no-op.

If
the sever has
the following
example
config:

<mycontainer>

<child
...
bla..bla…configs>

</mycontainer>

If
a client
issues an
edit-config
with:

< mycontainer operation="delete">

The
server returns
“ok”,

If
then again
the client
attempts:

< mycontainer operation="delete">

The
server should
still return
“ok”?

Yes,
that's correct
in my opinion.
It's a
consequence of
the NP
container
nature as
defined in the
current
RFC6020/YANG
1.0 and bis.

If
so I think
this is
confusing. I
think it would
make more
sense in the
latter case if
the server
returns “"data-missing”
error.

This is
logical if you
think of NP
containers as
path prefixes,
and not as
objects with
information
content. If
you accept
that an NP
container has
zero bits of
information,
how would the
server even
know whether
the container
exists or not?
Not by looking
in a database,
for sure.

P
containers
have a single
bit of
information,
so they can be
created, and
the creation
event/existence
remembered by
the server.
Not so for
NP-containers.

I
understand we
may advise a
client not do
so, but since
RFC6020bis
does not
forbid this,
and it is also
a perfectly
valid
<edit-config>,
so I am sure
people will
try it.

Yes. And
it works today
and is
harmless.

It's
unfortunate
that the YANG
1.0 and 1.1
specs aren't
crystal clear
on the
subject, but I
believe the
interpretation
I and others
have of NP
container
behavior in
RFC 6020 is
consistent,
implementable
and highly
useful.

/jan

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

_______________________________________________

Netconf mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________

Netconf mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani

[email-masked]

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 1 Aug 2016 11:02:45 +0200

Hello,

IMHO I feel it will be difficult to agree on the existence of
NP-Containers. Can we agree at least that protocol operations
shall not fail because of the existence/non-existence of
NP-Containers?

The RFC contains:

"non-presence container: A container that has no meaning of
its  own"

"the presence of the container node with no child nodes is
semantically equivalent to the absence of the container node.
YANG calls this style a non-presence container."

Semantically equivalent to me means the result of an operation
MUST not depend on the NP-container.

Balazs

On 2016-07-31 19:45, Mahesh
Jethanandani wrote:

I think this argument of whether server should or should not
create/delete NP containers is distracting from the main point of
when NP containers should exist. In my mind, the NP container
existence depends on whether child nodes exist or not. In the end,
if child nodes exist, NP containers should exist (created), if
they do not exist, the NP container should be removed.

Can we agree on that?

---

From: t.petch <[email-masked]>
Date: Mon, 1 Aug 2016 10:47:44 +0100

<inline <tp>>

---- Original Message -----
From: "Andy Bierman" <[email-masked]>
Sent: Monday, August 01, 2016 1:23 AM
On Sun, Jul 31, 2016 at 10:45 AM, Mahesh Jethanandani <
[email-masked]> wrote:
> On Jul 30, 2016, at 5:31 PM, Andy Bierman <[email-masked]> wrote:
> On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani <
> [email-masked]> wrote:
>
>> Andy,
>>
>> The thread started because the RFC does not say anything about a
create
>> of a NP container. It only talked about delete. Can we make the
(re-)create
>> of the NP container unconditional to whether a delete was performed
on it.
>> So a tweak to your proposal would be:
>>
> The only reason that example did not work is because the server
deleted
> the NP containers
> after the client created them.  If the server does not delete the
> containers then
create/delete
> NP containers is distracting from the main point of when NP containers
> should exist. In my mind, the NP container existence depends on
whether
> child nodes exist or not. In the end, if child nodes exist, NP
containers
> should exist (created), if they do not exist, the NP container should
be
> removed.

No.

"should be removed" is an implementation choice.
It started as MAY be removed.  It needs to stay that way.

As I have pointed out 100 times,  the protocol has merge and replace
for the situation where the client is not exactly aware of how ceration
and
deletion will be handled on the server.

<tp>

I think that Andy is spot on.  We currently have a simple, clear rule in
NETCONF:
- delete, does not exist, error
- create, does exist, error.

Introducing corner cases that blur the rules, that allow users to be
imprecise, whether by Standards Track RFC or an Erratum,
I think a mistake

An Erratum that points out that since a server may silently delete a
Non-Presence Container with no children, a user can never know whether
or not such a Container exists and so cannot know whether a delete or
create to be an error or not, yes, that is fine.  Going beyond that is a
protocol change (which I would resist even in an RFC).

Tom Petch

There is no reason to force implementations to change.
If you magically delete containers, then magically recreate them.
If you don't then the nodes will be as the client expects, so no
problem.

Andy

>
> P.s The errata will be much easier to craft if we can agree on this.
>
>
> This can also be completely avoided by using the default (merge).
> Since the client has to explicitly pick default-operation=none,
> This is the same issue as a default leaf
> and the create operation.  Nothing special about NP containers.
>
> The <edit-config> for "create" will fail if the leaf already exists
> and the "delete" will fail if the value is not there (just a default).
> The work-around?  Use merge and remove, not create and delete.
>>    If a container does not have a "presence" statement and the last
>>    child node is deleted, the NETCONF server MAY delete the
container.
>>
>> NEW:
>>
>>    If a container does not have a "presence" statement and the
container
>> instance
>>    does not have any child node instances, the NETCONF server MAY
delete
>> the
>>    container. It MUST create the container instance if a client
>> <edit-config> request
>>    attempts to create a child node instance within this container.
>>
>>
>> On Jul 30, 2016, at 11:52 AM, Andy Bierman <[email-masked]>
wrote:
>>
>> Hi,
>>
>> I strongly object to changing a vague MAY about deleting an NP
container
>> after the last child has been deleted into several MUST requirements.
>>
>> I propose this text instead:
>>
>> OLD:
>>
>>
>>    If a container does not have a "presence" statement and the last
>>    child node is deleted, the NETCONF server MAY delete the
container.
>>
>>
>> NEW:
>>
>>
>>    If a container does not have a "presence" statement and the
container
>> instance
>>    does not have any child node instances, the NETCONF server MAY
delete
>> the
>>    container. If the server does delete a container instance in this
>> case, it MUST
>>    re-create the container instance if a client <edit-config> request
>> attempts to create
>>    a child node instance within this container.
>>
>>
>>
>>
>> Andy
>>
>>
>> On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel <
>> [email-masked]> wrote:
>>
>>> Hello,
>>>
>>> We seem to have fundamental differences whether NP-containers
>>> exist/don't exist or if this question is even valid.  I hope we can
agree
>>> that as NP-containers are meaningless themselves they MUST NOT
influence
>>> Netconf operations or model validation. (Which is a slight violation
of
>>> Netconf-6241, which we should accept.)
>>>
>>> So I propose the following errata to rfc6020bis.
>>>
>>> As for non-presence containers the presence of the container node
with
>>> no child nodes is
>>> semantically equivalent to the absence of the container node,
>>> configuration operations or
>>> model validation should never fail due to the existence or
non-existence
>>> of a non-presence containers. Specifically:
>>>
>>> - an <edit-config>  create operation for a non-presence container
MUST
>>> succeed even if the container already exists.
>>> - an <edit-config>  delete operation for a non-presence container
MUST
>>> succeed even if the container does not exist.
>>> - an <edit-config>  operation with default-operation=none MUST
succeed
>>> even if one or more  non-presence containers do not exist.
>>>
>>> Separately
>>> - a must statement defined as direct substatement of a non-presence
>>> container SHALL be evaluated as part of model validation if and only
if one
>>> or more child data nodes exist in the instance data or if there is a
leaf
>>> or leaf-list child with a default value. As non-presence containers
are
>>> only used for organizing the hierarchy they SHOULD NOT have any must
>>> substatements.
>>> IMO the above rules remove ambiguity and follow the current
philosophy
>>> of  RFC6020bis.
>>> If we have a basic agreement I can formulate the text correctly.
>>>
>>> I don't know whether similar updates are needed for RestConf.
>>> regards Balazs
>>>
>>> PS. I still believe introducing NP containers was a mistake, however
>>> they are here to stay.
>>>
>>> On 2016-07-21 09:17, Jan Lindblad wrote:
>>>
>>> Xiang,
>>>
>>> Are you saying that since a NP-container is merely a structure node,
not
>>> config in any way, so creating/deleting it explicitly (and
repeatedly) is
>>> equivalent to a “no-op” that will always succeed because doing so
has no
>>> effect on the server’s config in any way?
>>>
>>>
>>> That's correct. "Creating" an object with zero bits of information
is a
>>> no-op.
>>>
>>> If the sever has the following example config:
>>> <mycontainer>
>>>      <child  ... bla..bla…configs>
>>> </mycontainer>
>>>
>>>
>>> If a client issues an edit-config with:
>>> The server returns “ok”,
>>> If then again  the client attempts:
>>>
>>> The server should still return  “ok”?
>>>
>>>
>>> Yes, that's correct in my opinion. It's a consequence of the NP
>>> container nature as defined in the current RFC6020/YANG 1.0 and bis.
>>>
>>>
>>> If so I think this is confusing. I think it would make more sense in
the
>>> latter case if the server returns “"data-missing” error.
>>>
>>>
>>> This is logical if you think of NP containers as path prefixes, and
not
>>> as objects with information content. If you accept that an NP
container has
>>> zero bits of information, how would the server even know whether the
>>> container exists or not? Not by looking in a database, for sure.
>>>
>>> P containers have a single bit of information, so they can be
created,
>>> and the creation event/existence remembered by the server. Not so
for
>>> NP-containers.
>>>
>>> I understand we may advise a client not do so, but since  RFC6020bis
>>> does not forbid this, and it is also a perfectly valid
<edit-config>, so I
>>> am sure people will try it.
>>>
>>>
>>> Yes. And it works today and is harmless.
>>>
>>> It's unfortunate that the YANG 1.0 and 1.1 specs aren't crystal
clear on
>>> the subject, but I believe the interpretation I and others have of
NP
>>> container behavior in RFC 6020 is consistent, implementable and
highly
>>> /jan

------------------------------------------------------------------------
--------

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 1 Aug 2016 12:19:55 +0200

IMHO not defining what happens is the worst solution. Any solution is 
better. If we can't agree, we should follow the Postel principle: be 
liberal in what you accept.

regards Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 Aug 2016 12:22:55 +0200

I agree with Tom and the 'solution' is IMHO to encourage clients to
use 'merge' instead of assuming a certain behavior here.

/js

On Mon, Aug 01, 2016 at 12:19:55PM +0200, Balazs Lengyel wrote:
> better. If we can't agree, we should follow the Postel principle: be liberal
> in what you accept.
> 
> regards Balazs
> 
> 

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

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 1 Aug 2016 12:34:50 +0200

This uncertainity makes default-operation=none fully unusable, and make 
create and delete unusable for NP-containers. That means 3 out of 6 
operations for Netconf 1.1 and 3 out of 5 for Netconf 1.0 are not 
properly defined. This is a BUG. We want to use create because with 
merge you can accidently create data-nodes.

Balazs

---

From: t.petch <[email-masked]>
Date: Mon, 1 Aug 2016 12:10:14 +0100

----- Original Message -----
From: "Balazs Lengyel" <[email-masked]>
Sent: Monday, August 01, 2016 9:55 AM

> Hello,
>
> As I see it:
>
> - The main problem is we don't agree whether or when NP containers
exist. Some people think they should exist (or not) just as any other
data node. (me, Andy, RFC6241) while others believe the existence of the
NP containers  is not even a valid question (tailf). As we have such
basic differences, I propose to focus just on the specific protocol
cases that are problematic.

Balazs

As a practical engineer, it is obvious to me that they exist.   A
response to a NETCONF 'get' may, or may not, contain them so it affects
the XML I receive, so they exist, period.  When I read that they do not
convey any information, I surmise that this is a statement from
Information Theory for some meaning of the word Information which likely
I do not understand.  But so what? The specification of Yang says I may
see them so when I do, I know that they exist.  The specification is
also very clear that I cannot rely on seeing them (if no child node
exists); such imprecision may or may not be a good thing in a Standard
but the text is very clear and unambiguous on this point.  As ever, how
a server achieves this is up to the server; what matters is the
appearance presented to the rest of the world, imprecise as it may be.

Looking back, I read

'A distinct container should be used when encoding lists with multiple
instances ...'
'Some containers exist in the 'real world' and some are only modelling
artefacts.'
'Use of container elements allows simpler manipulation of lists and list
members.'

which, for me, is the rationale for the two types of containers we have.
A Non-Presence Container makes life simpler for the data modeller and
the user of the data model.

Tom Petch

> - IMHO this problem means that the following 3 cases are not properly
defined and we need to clarify them. Saying the client should just not
use major parts of the protocol for NP-containers is wrong.
container
> 2) what happens if you create an NP-container and that already exists
e.g. you issue create twice
them properly.
> regards Balazs
>
>
> On 2016-08-01 02:23, Andy Bierman wrote:
>
>
>
>
>
>   On Sun, Jul 31, 2016 at 10:45 AM, Mahesh Jethanandani
wrote:
>
>
>
>
>
>
>       On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani
<[email-masked]> wrote:
>
>         Andy,
>
>
>         The thread started because the RFC does not say anything about
a create of a NP container. It only talked about delete. Can we make the
(re-)create of the NP container unconditional to whether a delete was
>       The only reason that example did not work is because the server
deleted the NP containers
>       after the client created them.  If the server does not delete
the containers then
>     I think this argument of whether server should or should not
create/delete NP containers is distracting from the main point of when
NP containers should exist. In my mind, the NP container existence
depends on whether child nodes exist or not. In the end, if child nodes
exist, NP containers should exist (created), if they do not exist, the
NP container should be removed.
>   for the situation where the client is not exactly aware of how
ceration and
problem.
last
container.
>            If a container does not have a "presence" statement and the
container instance
>            does not have any child node instances, the NETCONF server
MAY delete the
>            container. It MUST create the container instance if a
client <edit-config> request
>           On Jul 30, 2016, at 11:52 AM, Andy Bierman
<[email-masked]> wrote:
>
>
>           Hi,
>
>
>           I strongly object to changing a vague MAY about deleting an
NP container
container.
>
>
>
>
>           NEW:
>
>
>
>
>              If a container does not have a "presence" statement and
the container instance
>              does not have any child node instances, the NETCONF
server MAY delete the
>              container. If the server does delete a container instance
in this case, it MUST
>              re-create the container instance if a client
<edit-config> request attempts to create
>           On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel
<[email-masked]> wrote:
>
>             Hello,
>
>
>             We seem to have fundamental differences whether
NP-containers exist/don't exist or if this question is even valid.  I
hope we can agree that as NP-containers are meaningless themselves they
MUST NOT influence Netconf operations or model validation. (Which is a
slight violation of Netconf-6241, which we should accept.)
>             As for non-presence containers the presence of the
container node with no child nodes is
>             semantically equivalent to the absence of the container
node, configuration operations or
non-existence of a non-presence containers. Specifically:
>
>             - an <edit-config>  create operation for a non-presence
container MUST succeed even if the container already exists.
>             - an <edit-config>  delete operation for a non-presence
container MUST succeed even if the container does not exist.
>             - an <edit-config>  operation with default-operation=none
MUST succeed even if one or more  non-presence containers do not exist.
>
>
>             Separately
>             - a must statement defined as direct substatement of a
non-presence container SHALL be evaluated as part of model validation if
and only if one or more child data nodes exist in the instance data or
if there is a leaf or leaf-list child with a default value. As
non-presence containers are only used for organizing the hierarchy they
SHOULD NOT have any must substatements.
>
>             IMO the above rules remove ambiguity and follow the
current philosophy of  RFC6020bis.
>             PS. I still believe introducing NP containers was a
mistake, however they are here to stay.
>                 Are you saying that since a NP-container is merely a
structure node, not config in any way, so creating/deleting it
explicitly (and repeatedly) is equivalent to a “no-op” that will
always succeed because doing so has no effect on the server’s config
in any way?
>
>
>               That's correct. "Creating" an object with zero bits of
information is a no-op.
>               Yes, that's correct in my opinion. It's a consequence of
the NP container nature as defined in the current RFC6020/YANG 1.0 and
bis.
>
>                 If so I think this is confusing. I think it would make
more sense in the latter case if the server returns “"data-missing”
error.
>
>
>               This is logical if you think of NP containers as path
prefixes, and not as objects with information content. If you accept
that an NP container has zero bits of information, how would the server
even know whether the container exists or not? Not by looking in a
database, for sure.
>
>
>               P containers have a single bit of information, so they
can be created, and the creation event/existence remembered by the
server. Not so for NP-containers.
>
>
>                 I understand we may advise a client not do so, but
since  RFC6020bis does not forbid this, and it is also a perfectly valid
<edit-config>, so I am sure people will try it.
>               It's unfortunate that the YANG 1.0 and 1.1 specs aren't
crystal clear on the subject, but I believe the interpretation I and
others have of NP container behavior in RFC 6020 is consistent,
implementable and highly useful.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 1 Aug 2016 07:41:49 -0400

> On Aug 1, 2016, at 6:22 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Agree. 

How do we articulate that in the RFC?

Mahesh Jethanandani
[email-masked]

---

From: Jan Lindblad <[email-masked]>
Date: Mon, 1 Aug 2016 14:17:41 +0200

Certainly unfortunate that even us experts have a hard time interpreting the old text. Disregarding the text for a moment, what behavior would make sense; what would be useful? Having two kinds of containers with different names that behave the same doesn't seem very useful to me. I know some of you might not agree completely, but it seems I and a lot of (IETF) modelers are finding containers that just groups things together logically, but have no information contents in themselves, are useful. If you look at the IETF models, NP containers are very common.

A couple of examples:

ietf-interfaces.yang:
  container interfaces {
    description
      "Interface configuration parameters.";

ietf-system.yang:
    container clock {
      description
        "Configuration of the system date and time properties.";

ietf-ip.yanf:
     container autoconf {
       description
         "Parameters to control the autoconfiguration of IPv6
          addresses, as described in RFC 4862.";

If we had wanted the "creation" of these containers to really make a difference, we could have/would have made them P containers, right? I know the old text may have made it unnecessarily hard to see, but tracking the creation and deletion of the objects above wouldn't really get us anything. Provides no value. The existence of these containers truly has no meaning. This notion is completely natural in the user interface part of the world (e.g. CLI). You don't put all menu choices in the same menu or same CLI submode, even though strictly speaking there is no functional difference where they are located. It's just makes it easier for people to find the right item without linear search through everything. This makes NP containers essential when modeling existing CLI behavior.

/jan

> On 1 aug. 2016, at 13:10, t.petch <[email-masked]> wrote:
> 
> From: "Balazs Lengyel" <[email-masked] <mailto:[email-masked]>>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 1 Aug 2016 14:31:11 +0100

Hi,

My interpretation is that NP containers only exist to give structure to 
any nodes that exist below them and their existence is not intended to 
impart any meaning beyond this.

The solution I would like to see is to maximize interoperability between 
NETCONF client and server implementations.  So suggest that:

1) We clarify the text for "rfc6020bis-14#section-7.5.8 
<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-14#section-7.5.8>" 
to make it clear that a server may delete an empty NP container at any 
time (rather than explicitly only when the last child element is 
deleted).  I.e. I propose the following change to 6020bis:

OLD:
"If a container does not have a "presence" statement and the last
    child node is deleted, the NETCONF server MAY delete the container."

NEW:
"If a container does not have a "presence" statement and has no
   child nodes, then the NETCONF server MAY delete the container."

2) An errata to rfc6241 that, for the purpose of maximizing 
interoperability, recommends:
  (i) Clients should use merge/replace/remove operations for np 
container nodes.
  (ii) Servers should avoid erroring on a create/delete/none operation 
on an np container node.

Thanks,
Rob

---

From: Jonathan Hansford <[email-masked]>
Date: Mon, 1 Aug 2016 14:58:45 +0100

Should 2(ii) not state “Servers should avoid erroring on a create/delete/none operation on an np container node that has no child nodes”?

Jonathan

From: Robert Wilton

---

From: t.petch <[email-masked]>
Date: Mon, 1 Aug 2016 15:02:51 +0100

----- Original Message -----
From: "Mahesh Jethanandani" <[email-masked]>
Sent: Monday, August 01, 2016 12:41 PM

> On Aug 1, 2016, at 6:22 AM, Juergen Schoenwaelder

Agree.

<tp>

s.7.5.8.end

A client cannot know whether or not a server has deleted a Non-Presence
Container when the last child node has been deleted and so cannot know
whether a "create" or "delete" will succeed or return an error.  The
client should use "merge" or "replace" instead of "create".

Tom Petch

>> better. If we can't agree, we should follow the Postel principle: be
liberal

Mahesh Jethanandani
[email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 01 Aug 2016 16:13:14 +0200

Andy Bierman <[email-masked]> writes:

> Hi,
>
> YANG 1.1 has been changed so the XPath is not really backward-compatible
> with YANG 1.0.  In YANG 1.1 NP-containers always exist if the non-NP parent
> is
> instantiated.

My mental model regarding NP-containers is that they are part of
the default contents of a datastore. If an NP-container is "in use"
(according to the same rules as specified in sec. 7.6.1 of 6020bis for
default leaves), then

- creating a child of this container succeeds,

- "must" expressions defined on this container apply.

Lada

>
> NETCONF and RESTCONF do not say anything about the server ignoring
> the rules for operation="create", operation="delete" and
> default-operation="none".
> IMO itr would be a really bad idea to continue spreading little protocol
> details
> in the YANG RFC.  People might read the protocol spec and (correctly) assume
> that the protocol does not trat NP containers special at all.
>
> If anything, the sentence about MAY delete needs to be removed because
> it is inconsistent with the XPath (always exists).
>
>
> Andy
>
>
> On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley <[email-masked]> wrote:
>
>> Mahesh Jethanandani <[email-masked]> writes:
>> > depends on whether child nodes exist or not. In the end, if child
>> > nodes exist, NP containers should exist (created), if they do not
>> > exist, the NP container should be removed.
>> >
>> > Can we agree on that?
>>
>> If the concept of a "non-presence container" makes any sense, then the
>> existence of an empty container must have exactly the same significance
>> as the non-extence of the container.
>>
>> Given that, we have to make sure the protocol is consistent with that
>> principle.  E.g., if you ask to create an element of a non-existing NP
>> container, it must succeed, because asking to create an element of an
>> existing but empty NP container succeeds.
>>
>> I don't see what all the consequences of this principle are, but if we
>> can't make the protocol consistent with it, then we can't properly
>> implement the concept of NP containers.
>>
>> Dale
>>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Robert Wilton <[email-masked]>
Date: Mon, 1 Aug 2016 15:22:07 +0100

Yes.

Thanks for the clarification,
Rob

On 01/08/2016 14:58, Jonathan Hansford wrote:
>
> Should 2(ii) not state “Servers should avoid erroring on a 
> create/delete/none operation on an np container node that has no child 
> nodes”?
>
>
> Jonathan
>
> *From: *Robert Wilton <mailto:[email-masked]>
> *Sent: *01 August 2016 14:42
> *To: *t.petch <mailto:[email-masked]>; Andy Bierman 
> <mailto:[email-masked]>; Mahesh Jethanandani 
> <mailto:[email-masked]>; Balazs Lengyel 
> <mailto:[email-masked]>; Netconf <mailto:[email-masked]>
> *Subject: *Re: [Netconf] What should a server response be? - depending 
> onNP-containers
>
> Hi,
>
> My interpretation is that NP containers only exist to give structure 
> to any nodes that exist below them and their existence is not intended 
> to impart any meaning beyond this.
>
> The solution I would like to see is to maximize interoperability 
> between NETCONF client and server implementations.  So suggest that:
>
>     From: "Balazs Lengyel"<[email-masked]> <mailto:[email-masked]>
>
>     <[email-masked]> <mailto:[email-masked]>  wrote:
>
>              On Jul 30, 2016, at 5:31 PM, Andy Bierman<[email-masked]> <mailto:[email-masked]>
>
>     wrote:
>
>     <[email-masked]> <mailto:[email-masked]>  wrote:
>
>                  Andy,
>
>              P.s The errata will be much easier to craft if we can agree on
>
>     this.
>
>                This can also be completely avoided by using the default
>
>     (merge).
>
>                The <edit-config> for "create" will fail if the leaf already
>
>     exists
>
>                and the "delete" will fail if the value is not there (just a
>
>     default).
>
>                     attempts to create a child node instance within this
>
>     container.
>
>     <[email-masked]> <mailto:[email-masked]>  wrote:
>
>                    Hi,
>
>                    after the last child has been deleted into several MUST
>
>     requirements.
>
>     <[email-masked]> <mailto:[email-masked]>  wrote:
>
>                      Hello,
>
>                      If we have a basic agreement I can formulate the text
>
>     correctly.
>
>                      I don't know whether similar updates are needed for
>
>     RestConf.
>
>                      regards Balazs
>
>     explicitly (and repeatedly) is equivalent to a â€œno-opâ€ that will
>
>     always succeed because doing so has no effect on the serverâ€™s config
>
>     in any way?
>
>                               <child  ... bla..blaâ€¦configs>
>
>                          </mycontainer>
>
>                          The server returns â€œokâ€,
>
>                          The server should still return  â€œokâ€?
>
>     more sense in the latter case if the server returns â€œ"data-missingâ€
>
>     error.
>
>         Mobile: +36-70-330-7909              email:
>
>     [email-masked] <mailto:[email-masked]>
>
>                  [email-masked] <mailto:[email-masked]>
>
>         --
>
>         Mobile: +36-70-330-7909              email:
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 1 Aug 2016 07:23:19 -0700

> - "must" expressions defined on this container apply.

NP containers were not always present in YANG 1.0.
The must-stmt only applied if they actually are present,
which is an implementation choice.

I don't understand all this special wording about "do not error if..."

NETCONF has explicit support for this exact use-case, called "merge".
This was done precisely to support these "don't error if..." cases.
So use "merge" if you want this functionality.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 1 Aug 2016 07:30:11 -0700

> How do we articulate that in the RFC?

There are many ways the client can prevent this issue:

 1) use default-operation=merge
 2) use an explicit nc:operation="merge" attribute in the NP-container node
 3) make sure to create a child node of the NP-container (or know the
     server is going to create child operational  nodes)

IMO the server SHOULD NOT delete client-created NP containers
because YANG 1.1 XPath says they are there even if they get deleted.

<tp>

Andy

> [email-masked]
> >>

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 1 Aug 2016 16:32:02 +0200

2i) Telling the client: you better not use parts of the RFC
(none/create/delete) because they are not defined in an
interoperable way is strange

2ii) Using the term SHOULD instead of MUST still means the
operation is equally justified to send back OK or ERROR. IMHO it
we should use MUST/SHALL not SHOULD. It is better than nothing
thought.

Balazs

On 2016-08-01 15:31, Robert Wilton
wrote:

Hi,

My interpretation is that NP containers only exist to give
structure to any nodes that exist below them and their existence
is not intended to impart any meaning beyond this.

The solution I would like to see is to maximize interoperability
between NETCONF client and server implementations.  So suggest
that:

1) We clarify the text for "rfc6020bis-14#section-7.5.8"
to make it clear that a server may delete an empty NP container at
any time (rather than explicitly only when the last child element
is deleted).  I.e. I propose the following change to 6020bis:

OLD:

container."

NEW:

(ii) Servers should avoid erroring on a create/delete/none
operation on an np container node.

Thanks,

Rob

----- Original Message -----
From: "Balazs Lengyel" <[email-masked]>
Sent: Monday, August 01, 2016 9:55 AM

Hello,

As I see it:

Balazs

Looking back, I read

Tom Petch

container

them properly.

regards Balazs

wrote:

Andy,

the containers then

Can we agree on that?

No.

ceration and

problem.

Andy

this.

(merge).

exists

default).

Andy

OLD:

last

container.

NEW:

container instance

MAY delete the

container.

Hi,

NP container

requirements.

OLD:

the last

container.

NEW:

the container instance

server MAY delete the

in this case, it MUST

Andy

Hello,

Separately

correctly.

RestConf.

regards Balazs

Xiang,

information is a no-op.

/jan

Mahesh Jethanandani
[email-masked]

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 1 Aug 2016 16:37:48 +0200

+1

IMHO removing empty NP-containers is a presentation issue and should not 
impact the protocol or the _conceptual_ database.

Balazs

---

From: William Ivory <[email-masked]>
Date: Mon, 1 Aug 2016 14:51:05 +0000

Hi,

Could someone confirm then that must statements on a non-presence container in YANG 1.0 are only to be evaluated if the non-presence container has configured children … or is it also if (reading Lada’s mail) the implementation chooses to implement them when there are no children present?

I had assumed that the text in YANG 1.1 was clarifying YANG 1.0 rather than new functionality here but I’m a little confused now, especially given the comment by Jan Lindblad regarding this YANG snippet as the file does not contain ‘yang-version 1.1’ and would surely therefore be version 1.0?

      container ownership-voucher {
        description
          "This container contains the Ownership Voucher that the
           device uses to ascertain the identity of its rightful
           owner, as certified by its Vendor.";

        when "../redirect-information/signature or ../bootstrap-information/*/signature";
        must "../owner-certificate";

        uses ownership-voucher-grouping;
      }

https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-zerotouch-bootstrap-server.yang

Jan’s comment on this YANG (assuming it’s 1.0) and Lada’s assertion (pasted below) appear contradictory to me.

‘NP containers were not always present in YANG 1.0.
The must-stmt only applied if they actually are present,
which is an implementation choice.
‘

I’m also thinking that any must statement on a non-presence container in YANG 1.0 models might sensibly be (re)written as ‘not(current() or <required_xpath_expression>’ to make it future-proof if these nodes do not exist in 1.0 w/o children but do in YANG 1.1.  That would allow for easier model migration.

Regards,

William

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: 01 August 2016 15:23
To: Ladislav Lhotka <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

On Mon, Aug 1, 2016 at 7:13 AM, Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:

Lada

Andy

> On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley <[email-masked]<mailto:[email-masked]>> wrote:
>
>> Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> writes:
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=CwMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=5DxGc18igLLazowEJRqflL2VzkC-HVcPxXuz7ltgGTg&s=lKQM7K6YaNT-kyuXsPRqluZ7lPWk84ZlasNmH288Iz0&e=>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 1 Aug 2016 08:03:05 -0700

Hi,

I think I made that comment.
In YANG 1.0, only default leafs were considered always present.
In YANG 1.1 NP containers were added to the set of accessible nodes

In YANG 1.0, sec. 7.5.3

   o  The accessible tree is made up of all nodes in the data tree, and
      all leafs with default values in use (see Section 7.6.1).

This was changed in YANG 1.1

sec 7.5.3:

   When a datastore is validated, all "must" constraints are
   conceptually evaluated once for each node in the accessible tree (see
   Section 6.4.1).

Sec. 6.4.1

      If a node that exists in the accessible tree has a non-presence
      container as a child, then the non-presence container also exists in
      the tree.

Andy

On Mon, Aug 1, 2016 at 7:51 AM, William Ivory <[email-masked]> wrote:

> Hi,
>
>
>
> Could someone confirm then that must statements on a non-presence
> container in YANG 1.0 are only to be evaluated if the non-presence
> container has configured children … or is it also if (reading Lada’s mail)
> the implementation chooses to implement them when there are no children
> present?
>
>
>
> I had assumed that the text in YANG 1.1 was clarifying YANG 1.0 rather
> than new functionality here but I’m a little confused now, especially given
> the comment by Jan Lindblad regarding this YANG snippet as the file does
> not contain ‘yang-version 1.1’ and would surely therefore be version 1.0?
>
>
>
> Jan’s comment on this YANG (assuming it’s 1.0) and Lada’s assertion
> (pasted below) appear contradictory to me.
>
>
>
> I’m also thinking that any must statement on a non-presence container in
> YANG 1.0 models might sensibly be (re)written as ‘not(current() or
> <required_xpath_expression>’ to make it future-proof if these nodes do not
> exist in 1.0 w/o children but do in YANG 1.1.  That would allow for easier
> model migration.
>
>
>
> Regards,
>
>
>
> William
>
>
>
> *From:* Netconf [mailto:[email-masked]] *On Behalf Of *Andy
> Bierman
> *Sent:* 01 August 2016 15:23
> *To:* Ladislav Lhotka <[email-masked]>
> *Cc:* Netconf <[email-masked]>
> *Subject:* Re: [Netconf] What should a server response be? - depending on
> NP-containers
>
>
>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=CwMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=5DxGc18igLLazowEJRqflL2VzkC-HVcPxXuz7ltgGTg&s=lKQM7K6YaNT-kyuXsPRqluZ7lPWk84ZlasNmH288Iz0&e=>
>
> --

---

From: William Ivory <[email-masked]>
Date: Mon, 1 Aug 2016 15:10:08 +0000

Hi Andy,

Thanks – in isolation that is clear, but I would be interested in Jan’s thoughts given that the given ownership-voucher example would appear to be YANG 1.0 *and* assume must statements are evaluated on non-presence containers if the parent node exists.

Regards,

William

From: Andy Bierman [mailto:[email-masked]]
Sent: 01 August 2016 16:03
To: William Ivory <[email-masked]>
Cc: Ladislav Lhotka <[email-masked]>; [email-masked]; Netconf <[email-masked]>
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

Hi,

In YANG 1.0, sec. 7.5.3

sec 7.5.3:

   Section 6.4.1).
Sec. 6.4.1

Andy

On Mon, Aug 1, 2016 at 7:51 AM, William Ivory <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-zerotouch-bootstrap-server.yang<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_YangModels_yang_blob_master_standard_ietf_DRAFT_ietf-2Dzerotouch-2Dbootstrap-2Dserver.yang&d=CwMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=U_qmt_V30Ip730gm0ZL0g9VOCtSGeXHHUwjrgXFUWEQ&s=vM3jDKzm_q-IBzQdneCUkMY710T1kZ-O2hh_VhSMdBo&e=>

Regards,

William

From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andy Bierman
Sent: 01 August 2016 15:23
To: Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>
Cc: Netconf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

Lada

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 1 Aug 2016 08:14:06 -0700

On Mon, Aug 1, 2016 at 8:10 AM, William Ivory <[email-masked]> wrote:

> Hi Andy,
>
>
>
> Thanks – in isolation that is clear, but I would be interested in Jan’s
> thoughts given that the given ownership-voucher example would appear to be
> YANG 1.0 **and** assume must statements are evaluated on non-presence
> containers if the parent node exists.
>
>
>

In YANG 1.0, must statements are clearly NOT evaluated for NP containers
just because
their parent exists.  That was the part that was added in YANG 1.1.

Andy

>
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* 01 August 2016 16:03
> *To:* William Ivory <[email-masked]>
> *Cc:* Ladislav Lhotka <[email-masked]>; [email-masked]; Netconf <
> [email-masked]>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_YangModels_yang_blob_master_standard_ietf_DRAFT_ietf-2Dzerotouch-2Dbootstrap-2Dserver.yang&d=CwMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=U_qmt_V30Ip730gm0ZL0g9VOCtSGeXHHUwjrgXFUWEQ&s=vM3jDKzm_q-IBzQdneCUkMY710T1kZ-O2hh_VhSMdBo&e=>
>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 1 Aug 2016 17:24:02 +0200

> On 01 Aug 2016, at 16:23, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

Hence ambiguous. I think that validity of a datastore must not depend on implementation choices.
This has been clarified in YANG 1.1, which is IMO good. 

> So use "merge" if you want this functionality.

What about RESTCONF? I don't see any reason why a PUT on a NP-container "in use" should fail.

Lada

---

From: Jan Lindblad <[email-masked]>
Date: Tue, 2 Aug 2016 14:12:32 +0200

Those of us who believe the presence statement in YANG 1.0 specifies some behavioral difference between P and NP containers tend to think of the YANG 1.1 specification edits below as clarifications rather than functional changes.

This should come as no surprise to anyone who has had the strength to follow the full length of the thread, but since my opinion was requested, I thought I'd clarify anyway.

As SDO our main goal should be to get clear specs describing useful functionality. NP containers, as defined in YANG 1.1 and (less clearly) in YANG 1.0 are very useful IMO. I would prefer to describe NP containers as always existing if the parent exists, but may be suppressed in get-config when empty. I proposed some specific language earlier. I find this more natural than language around spontaneous creation and deletion by the server, even if the net result may be the same. The voucher example is indeed YANG 1.0.

/jan

> On 1 aug. 2016, at 17:10, William Ivory <[email-masked]> wrote:
> 
> Hi Andy,
> 
> On Mon, Aug 1, 2016 at 7:51 AM, William Ivory <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-zerotouch-bootstrap-server.yang <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_YangModels_yang_blob_master_standard_ietf_DRAFT_ietf-2Dzerotouch-2Dbootstrap-2Dserver.yang&d=CwMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=U_qmt_V30Ip730gm0ZL0g9VOCtSGeXHHUwjrgXFUWEQ&s=vM3jDKzm_q-IBzQdneCUkMY710T1kZ-O2hh_VhSMdBo&e=>
> 
> From: Netconf [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Andy Bierman
> To: Ladislav Lhotka <[email-masked] <mailto:[email-masked]>>
> Cc: Netconf <[email-masked] <mailto:[email-masked]>>
> On Mon, Aug 1, 2016 at 7:13 AM, Ladislav Lhotka <[email-masked] <mailto:[email-masked]>> wrote:
> Andy Bierman <[email-masked] <mailto:[email-masked]>> writes:
> 
> > Hi,
> >
> > On Sun, Jul 31, 2016 at 6:13 PM, Dale R. Worley <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >> Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> writes:
> > https://www.ietf.org/mailman/listinfo/netconf <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=CwMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=5DxGc18igLLazowEJRqflL2VzkC-HVcPxXuz7ltgGTg&s=lKQM7K6YaNT-kyuXsPRqluZ7lPWk84ZlasNmH288Iz0&e=>
> 
> --

---

From: William Ivory <[email-masked]>
Date: Tue, 2 Aug 2016 12:40:34 +0000

So if I were to implement the decision on whether to evaluate musts on NP containers that have no children using random(), that would meet the spec? (-:

From the perspective of writing our YANG 1.0 models, we can add ‘not current() or …’ on the front of any must statement on a NP container if we only want it to be evaluated when the NP container has child node(s).  That at least relaxes restrictions (so meets RFC 6020 section 10 backwards-compatibility requirements) and reduces the number of NP containers where evaluation of must statements would appear to be implementation-specific for YANG 1.0.

From Jan’s perspective I can see that not evaluating must statements on NP containers with no child nodes would invalidate his YANG model, but equally any NP container with the likes of ‘must “not(../foo)”;’ would make configuration of ‘foo’ impossible if we take the 1.1 clarification and apply it to 1.0.  Unless there is existing clear guidance that the latter form of must statement should (must?) be avoided, then I don’t see any overpowering argument in either direction.  It comes down perhaps to whether we prefer to allow some configurations that weren’t intended to be allowed (not evaluating musts that were intended to be evaluated) or we potentially block valid configurations (evaluating musts that weren’t intended to always be evaluated).

From a pragmatic perspective, the Postel principle of being liberal in what you accept (at least in YANG) would seem more flexible in that once config is rejected, there’s no alternative, whereas you can always advise that configuration is accepted but ‘unwise’.

I’m not familiar enough with IETF procedures to know how this should be resolved so would appreciate advice!

Thanks,

William

From: Jan Lindblad [mailto:[email-masked]]
Sent: 02 August 2016 13:13
To: William Ivory <[email-masked]>; Andy Bierman <[email-masked]>
Cc: Ladislav Lhotka <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

/jan

On 1 aug. 2016, at 17:10, William Ivory <[email-masked]<mailto:[email-masked]>> wrote:

Hi Andy,

Regards,

William

From: Andy Bierman [mailto:[email-masked]]
Sent: 01 August 2016 16:03
To: William Ivory <[email-masked]<mailto:[email-masked]>>
Cc: Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Netconf <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

Hi,

In YANG 1.0, sec. 7.5.3

sec 7.5.3:

   Section 6.4.1).
Sec. 6.4.1

Andy

Regards,

William

Lada

Andy

---

From: Jan Lindblad <[email-masked]>
Date: Tue, 2 Aug 2016 16:43:26 +0200

> So if I were to implement the decision on whether to evaluate musts on NP containers that have no children using random(), that would meet the spec? (-:

Not at all. I hate to repeat myself, but this is a long thread, so here is a summary again:

The YANG 1.0 spec introduces the presence statement and explains how NP containers differ from P containers. Among other things, it's noted that NP containers have no information content and no meaning in themselves. Their "existence" is therefore meaningless and their zero bits of information implies no such state can be remembered by a compliant server. I.e. they always exist, even if they MAY be "deleted" from the output when empty since they are meaningless. YANG 1.1 makes this a bit clearer, but doesn't change anything functionally IMO.

If NP containers could be "created" and "deleted", what benefit would that bring? If they could, what would be the purpose with the presence statement? Why any distinction between P and NP containers at all? I have asked these questions on this list several times in different words over the last weeks, and so far zero answers. Could someone who defends the position that NP containers can meaningfully be created and deleted comment on this? IMO, the lack of answers makes it increasingly difficult to take this stance seriously.

> From the perspective of writing our YANG 1.0 models, we can add ‘not current() or …’ on the front of any must statement on a NP container if we only want it to be evaluated when the NP container ha…

YANG 1.1 implies no functional change, so there is no need to update any models. I understand (and have preached this for many years in YANG trainings, as many readers of this list might testify) that clarifications always have an element of backwards incompatibility, as anyone who understood the original unclear statement differently after the clarification will see a change...

Even if "not current() or " is prepended to must expressions, that would have no effect at all. The expression would only be evaluated for nodes that do exist, so bool(current()) is always true for any node that has its must expressions evaluated.

> From Jan’s perspective I can see that not evaluating must statements on NP containers with no child nodes would invalidate his YANG model,

I certainly have many examples of this in my world, but this model was taken from the IETF YANG repo. Zerotouch, to be exact.

Beside my point that seasoned IETF modelers that have nothing to do with me or our tools leverage this understanding of NP containers, it also highlights the utility of the NP container concept as I interpret it. YANG would clearly lose something if we made NP containers behave the same as P containers.

> but equally any NP container with the likes of ‘must “not(../foo)”;’ would make configuration of ‘foo’ impossible if we take the 1.1 clarification and apply it to 1.0.

I reiterate that there is no change, just a clarification in YANG 1.1.

> Unless there is existing clear guidance that the latter form of must statement should (must?) be avoided, then I don’t see any overpowering argument in either direction.

There is no such guidance, and there shouldn't be. This is a useful way to express validity of configurations in YANG. I find the zerotouch example elegant and simple to understand. The YANG modile would only get less readable if we tried to add some rules/CLRs to forbid certain must statement constructs, not to mention the YANG spec itself.

>   It comes down perhaps to whether we prefer to allow some configurations that weren’t intended to be allowed (not evaluating musts that were intended to be evaluated) or we potentially block valid configurations (evaluating musts that weren’t intended to always be evaluated).

Is this a real problem? Do we have a lot of models that depend on the (mis)understanding of how must statements on NP containers are evaluated?

> From a pragmatic perspective, the Postel principle of being liberal in what you accept (at least in YANG) would seem more flexible in that once config is rejected, there’s no alternative, whereas y…

I simply cannot imagine that leaving open whether must statements are to be evaluated or not could bring this WG closer to any of its goals. We should be working towards precision and utility.

/jan

> On 1 aug. 2016, at 17:10, William Ivory <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Andy,
> 
> From: Andy Bierman [mailto:[email-masked] <mailto:[email-masked]>]
> To: William Ivory <[email-masked] <mailto:[email-masked]>>
> Cc: Ladislav Lhotka <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Netconf <[email-masked] <mailto:[email-masked]>>

---

From: t.petch <[email-masked]>
Date: Tue, 2 Aug 2016 17:20:39 +0100

----- Original Message -----
From: "Jan Lindblad" <[email-masked]>
To: "William Ivory" <[email-masked]>
Cc: "Netconf" <[email-masked]>
Sent: Tuesday, August 02, 2016 3:43 PM

<snip>
If NP containers could be "created" and "deleted", what benefit would
that bring? If they could, what would be the purpose with the presence
statement? Why any distinction between P and NP containers at all? I
have asked these questions on this list several times in different words
over the last weeks, and so far zero answers. Could someone who defends
the position that NP containers can meaningfully be created and deleted
comment on this? IMO, the lack of answers makes it increasingly
difficult to take this stance seriously.

<tp>
To quote from an early I-D,

A distinct container should be used when encoding lists with multiple
instances...
Some containers exist in the 'real world' and some are only modelling
artefacts.
Use of container elements allows simpler manipulation of lists and list
members.

so I have always seen the value of containers, those that exist and
those that are artefacts.  Giving some a boolean value (calling it one
bit of information sounds like information theory to me:-) is a
plausible extension of this but making them possibly vanish when empty
has seemed a little odd; suppressing them in a response, well yes, sort
of ok.

So I see the root of the problem as the defined, but indeterminate,
behaviour that a YANG server is allowed when a Non-Presence container is
empty.  One post of Andy did suggest changing that and that I think the
best way forward (but I would see that as more than a permissible
erratum).  I see the change of text in YANG 1.1 relating to must
statements as steering us in that direction

As to the IETF procedure, the WG Chairs assess rough consensus, declare
it and we move on (leaving those unhappy with it with the option to
appeal:-).  Sometimes, as at this moment with IPv6 and the insertion of
Extension Headers, that can be a protracted process.  And the main IETF
list is discussing how long the IETF takes to produce a standard and the
downsides thereof.

Tom Petch

> From the perspective of writing our YANG 1.0 models, we can add ‘not
current() or …’ on the front of any must statement on a NP container if
we only want it to be evaluated when the NP container has child node(s).
That at least relaxes restrictions (so meets RFC 6020 section 10
backwards-compatibility requirements) and reduces the number of NP
containers where evaluation of must statements would appear to be
implementation-specific for YANG 1.0.

YANG 1.1 implies no functional change, so there is no need to update any
models. I understand (and have preached this for many years in YANG
trainings, as many readers of this list might testify) that
clarifications always have an element of backwards incompatibility, as
anyone who understood the original unclear statement differently after
the clarification will see a change...

Even if "not current() or " is prepended to must expressions, that would
have no effect at all. The expression would only be evaluated for nodes
that do exist, so bool(current()) is always true for any node that has
its must expressions evaluated.

> From Jan’s perspective I can see that not evaluating must statements
on NP containers with no child nodes would invalidate his YANG model,

I certainly have many examples of this in my world, but this model was
taken from the IETF YANG repo. Zerotouch, to be exact.

Beside my point that seasoned IETF modelers that have nothing to do with
me or our tools leverage this understanding of NP containers, it also
highlights the utility of the NP container concept as I interpret it.
YANG would clearly lose something if we made NP containers behave the
same as P containers.

> but equally any NP container with the likes of ‘must “not(../foo)”;’
would make configuration of ‘foo’ impossible if we take the 1.1
clarification and apply it to 1.0.

> Unless there is existing clear guidance that the latter form of must
statement should (must?) be avoided, then I don’t see any overpowering
argument in either direction.

There is no such guidance, and there shouldn't be. This is a useful way
to express validity of configurations in YANG. I find the zerotouch
example elegant and simple to understand. The YANG modile would only get
less readable if we tried to add some rules/CLRs to forbid certain must
statement constructs, not to mention the YANG spec itself.

>   It comes down perhaps to whether we prefer to allow some
configurations that weren’t intended to be allowed (not evaluating musts
that were intended to be evaluated) or we potentially block valid
configurations (evaluating musts that weren’t intended to always be
evaluated).

Is this a real problem? Do we have a lot of models that depend on the
(mis)understanding of how must statements on NP containers are
evaluated?

> From a pragmatic perspective, the Postel principle of being liberal in
what you accept (at least in YANG) would seem more flexible in that once
config is rejected, there’s no alternative, whereas you can always
advise that configuration is accepted but ‘unwise’.

I simply cannot imagine that leaving open whether must statements are to
be evaluated or not could bring this WG closer to any of its goals. We
should be working towards precision and utility.

/jan

> Those of us who believe the presence statement in YANG 1.0 specifies
some behavioral difference between P and NP containers tend to think of
the YANG 1.1 specification edits below as clarifications rather than
functional changes.
>
> This should come as no surprise to anyone who has had the strength to
follow the full length of the thread, but since my opinion was
requested, I thought I'd clarify anyway.
>
> As SDO our main goal should be to get clear specs describing useful
functionality. NP containers, as defined in YANG 1.1 and (less clearly)
in YANG 1.0 are very useful IMO. I would prefer to describe NP
containers as always existing if the parent exists, but may be
suppressed in get-config when empty. I proposed some specific language
earlier. I find this more natural than language around spontaneous
creation and deletion by the server, even if the net result may be the
same. The voucher example is indeed YANG 1.0.
> Thanks – in isolation that is clear, but I would be interested in Jan’
s thoughts given that the given ownership-voucher example would appear
to be YANG 1.0 *and* assume must statements are evaluated on
non-presence containers if the parent node exists.
container in YANG 1.0 are only to be evaluated if the non-presence
container has configured children … or is it also if (reading Lada’s
mail) the implementation chooses to implement them when there are no
children present?
> I had assumed that the text in YANG 1.1 was clarifying YANG 1.0 rather
than new functionality here but I’m a little confused now, especially
given the comment by Jan Lindblad regarding this YANG snippet as the
file does not contain ‘yang-version 1.1’ and would surely therefore be
version 1.0?
>         uses ownership-voucher-grouping;
https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-
zerotouch-bootstrap-server.yang
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_YangMod
els_yang_blob_master_standard_ietf_DRAFT_ietf-2Dzerotouch-2Dbootstrap-2D
server.yang&d=CwMFaQ&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDr
xizlOR7l_SnTXowyJU8&m=U_qmt_V30Ip730gm0ZL0g9VOCtSGeXHHUwjrgXFUWEQ&s=vM3j
DKzm_q-IBzQdneCUkMY710T1kZ-O2hh_VhSMdBo&e=>
> I’m also thinking that any must statement on a non-presence container
in YANG 1.0 models might sensibly be (re)written as ‘not(current() or
<required_xpath_expression>’ to make it future-proof if these nodes do
not exist in 1.0 w/o children but do in YANG 1.1.  That would allow for
easier model migration.
>
> Regards,
>
> William
>
> From: Netconf [mailto:[email-masked]
<mailto:[email-masked]>] On Behalf Of Andy Bierman
> > is instantiated.

---

From: Phil Shafer <[email-masked]>
Date: Tue, 2 Aug 2016 13:47:58 -0400

Jan Lindblad writes:
>I would prefer to describe NP containers as always existing if the parent exists, but may be suppressed in get-config when empty.

I wrote something for the last IETF that was described as completely
accurate technically but semantically confusing.  I would consider
this "always existing" to be similar.  The point to convey is that
the NP container is strictly an organizational node, and that their
presence in the hierarchy carries no meaning.  They are used when
containing other nodes and have no value when they do not contain
other nodes.  If none of the nodes they contain exist, they should
not be visible.  If one or more of the nodes they contain exist,
they should be visible.   Make them always exist adds confusion.

Thanks,
 Phil

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 3 Aug 2016 13:35:00 +0200

> they should be visible.   Make them always exist adds confusion.

I'm fine with this. Maybe we should clarify that must statements on NP containers are evaluated if the NP container parent exists. That's where the "always exists" notion might help understanding a bit.

/jan

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 03 Aug 2016 10:36:45 -0400

Jan Lindblad <[email-masked]> writes:
> I'm fine with this. Maybe we should clarify that must statements on NP
> containers are evaluated if the NP container parent exists. That's
> where the "always exists" notion might help understanding a bit.

(I'm not as versed in this technology as the rest of you, but...)

Why would there be a must statement on an NP container?  If its
existence is semantically meaningless, why would the module designer
place a must on it, since a must statement is a constraint of the form
"If this node exists, then this expression must be true."

Probably what is intended is to place a must statement on the *children*
of the container, which has the effect "If this container has contents,
then this expression must be true."

Similarly, there should be no XPath expressions whose purpose is to test
for the presence of an NP container.

Dale

---

From: Andy Bierman <[email-masked]>
Date: Wed, 3 Aug 2016 07:51:57 -0700

> then this expression must be true."

I like this clarification a lot.
I think this change is worth an errata (or maybe AUTH48 change).

The text that says an NP container exists if its parent exists is not
consistent with the results of this discussion.  It should say an NP
container exists if any child nodes exist or default nodes exist.

In this example 'top' and 'top2' always exist because of the default leaf X.

  container top {
    container top2 {
       leaf X {
          type int32;
          default 42;
      }
   }
 }

In this example 'top' and 'top2' only when leaf /top/top2/X exists.

  container top {
    container top2 {
       leaf X {
          type int32;
      }
   }
 }

Andy

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 3 Aug 2016 11:18:15 -0400

Here is the summary of rough consensus that I see emerging.

1. Errata in YANG 1.1 Section 7.5.7 to clarify that NP containers exist (and return values) when it contains a node. Some suggested text.

    OLD:
  
     A NETCONF server that replies to a <get> or <get-config> request MAY
     choose not to send a container element if the container node does not
     have the "presence" statement and no child nodes exist.

    NEW:

     A NETCONF server that replies to a <get> or <get-config> request SHOULD
     not send a container element if the container node does not
     have the "presence" statement and no child or default nodes exist. Similarly, must
     statements SHOULD be evaluated for the children of the container.

2. Errata in YANG 1.1 to add the following clarification at the end of section 7.5.8

    A client cannot know whether or not a server has deleted a non-presence
    container when the last child node has been deleted and so cannot know
    whether a "create" or "delete" will succeed or return an error.  The
    client should use "merge" or "replace" instead of "create”.

3. Errata in YANG 1.1. to add the following clarification in the same section (7.5.8)

OLD:

   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.

NEW:

   If a container does not have a "presence" statement and the container instance
   does not have any child node instances, the NETCONF server MAY delete the
   container. If the server does delete a container instance in this case, it MUST
   re-create the container instance if a client <edit-config> request attempts to create
   a child node instance within this container.

> On Aug 3, 2016, at 7:35 AM, Jan Lindblad <[email-masked]> wrote:
> 

Mahesh Jethanandani
[email-masked]

---

From: William Ivory <[email-masked]>
Date: Wed, 3 Aug 2016 16:28:59 +0000

Surely we should either evaluate on ALL non-presence containers, or none?  After all, we evaluate 'default' and 'mandatory' anywhere in the config even if no actively configured nodes are anywhere in the vicinity?  Only evaluating to a depth of one level under configured nodes seems somewhat arbitrary.

Regards,

William

-----Original Message-----
From: Jan Lindblad [mailto:[email-masked]] 
Sent: 03 August 2016 12:35
To: Phil Shafer <[email-masked]>
Cc: William Ivory <[email-masked]>; Andy Bierman <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

> this "always existing" to be similar.  The point to convey is that the 
> NP container is strictly an organizational node, and that their 
> other nodes.  If none of the nodes they contain exist, they should not 
> be visible.  If one or more of the nodes they contain exist,

/jan

---

From: Andy Bierman <[email-masked]>
Date: Wed, 3 Aug 2016 09:33:47 -0700

On Wed, Aug 3, 2016 at 9:28 AM, William Ivory <[email-masked]> wrote:

> Surely we should either evaluate on ALL non-presence containers, or none?
> After all, we evaluate 'default' and 'mandatory' anywhere in the config
> even if no actively configured nodes are anywhere in the vicinity?  Only
> evaluating to a depth of one level under configured nodes seems somewhat
> arbitrary.
>
>
The text currently says what you suggest.
But if the NP containers have no meaning as some claim,
then they only exist when descendant nodes with meaning exist.
Why do they exist if they have no meaning?

Regards,

Andy

> containers are evaluated if the NP container parent exists. That's where
> the "always exists" notion might help understanding a bit.
>
> /jan
>
>

---

From: Phil Shafer <[email-masked]>
Date: Wed, 3 Aug 2016 15:42:08 -0400

>the "always exists" notion might help understanding a bit.

Or say that their existance is meaningless and carries no semantic
value, and must/when conditions should never consider or depend
on their existence.

Thanks,
 Phil

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 4 Aug 2016 01:17:55 +0200

> 1. Errata in YANG 1.1 Section 7.5.7 to clarify that NP containers exist (and return values) when it contains a node. Some suggested text.

That must statements on NP containers SHOULD be considered only when it contains a node is problematic.

First of all, I find a SHOULD on whether a must statement is evaluated or not deeply problematic. Secondly, even if this was turned into a MUST iff, I find this difficult in practice.

With this definition, a reader would have a hard time knowing whether the must statement applies. The reader would have to go through the full contents of the container, check if any leaf has a mandatory or default statement in it, or if any subordinate container, grouping or typedef does, transitively. For a container with three leaf children, fine, but there are containers out there where this would take more than an hour to find out.

And what about RFC 6020 section 10? It says that the addition of a default statement is considered a backwards-compatible model change. Such changes could easily modify the semantics of existing must statements on containers.

So while I can see some appeal with the suggested text, in practice I think it's a bad idea to tie the evaluation of NP container must statements to the existence of child nodes.

> But if the NP containers have no meaning as some claim,

Well, this claim comes from RFC 6020:

7.5.1 <https://tools.ietf.org/html/rfc6020#section-7.5.1>.  Containers with Presence

   YANG supports two styles of containers, those that exist only for
   organizing the hierarchy of data nodes, and those whose presence in
   the configuration has an explicit meaning.

   In the first style, the container has no meaning of its own, existing
   only to contain child nodes.  This is the default style.

> Why do they exist if they have no meaning?

As humans, we like to organize things. We could have written
leaf ipv4-enabled { ... }
leaf ipv4-forwarding { ... }
leaf ipv4...
list ipv4-address { ... }
leaf ipv6-enabled { ... }
leaf ipv6-forwarding { ... }
...

For us humans, this set of data is easier to consume if we added some structure with containers. Logically, the information content is the same regardless which form we use.

This is what we have done for decades in our CLIs. To reflect existing CLI structure, we need the containers. The YANG models already out there prove this point well.

In existing CLIs, certain keywords exist in the command syntax only to group related commands together. If you type only the stem of this command, that will have no effect. I've never heard operators discussing whether the stem "exists" or not. This is what I have a need to model. I have been using NP containers for this.

IOS:
class-map X ip dscp ...
class-map X ip presedence ...
In itself "class-map X ip" doesn't do anything.

FTOS:
hardware watchdog
In itself "hardware" doesn't do anything.

JUNOS:
system host-name ...
system autoinstallation ...
In itself "system" doesn't do anything.

If we have to build our NETCONF servers such that they can remember a "creation" of "class-map X ip", "hardware" and "system", what value would that add? The underlaying OS has no notion of any existence of these "objects".

> value, and must/when conditions should never consider or depend

I agree, but the issue of when must statements sitting on an NP container are evaluated needs some clarification.

/jan

---

From: Robert Wilton <[email-masked]>
Date: Thu, 4 Aug 2016 10:54:22 +0100

> value, and must/when conditions should never consider or depend
Does that mean that for an empty NP container, it would be up to the 
server to decide whether or not to evaluate the containers must/when 
statements?  But if the NP container exists due to existence of child 
nodes then the must/when statements would be guaranteed to be evaluated 
by the server?

Thanks,
Rob

> .

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 4 Aug 2016 13:13:09 +0200

Hello Mahesh,

I like your text if you clarify that a deleted NP-container MUST not
be reason for an edit-config operation=none to fail.

Balazs

On 2016-08-03 17:18, Mahesh
Jethanandani wrote:

3. Errata in YANG 1.1. to add the following
clarification in the same section (7.5.8)

OLD:

If
a container does not have a "presence"
statement and the last

child node is deleted, the NETCONF server MAY
delete the container.

NEW:

If a container does not have a "presence"
statement and the container instance

does not have any child node instances, the
NETCONF server MAY delete the

container. If the server does delete a
container instance in this case, it MUST

a
child node instance within this container.

BALAZS: This good, but it MUST be reworded so default-operation=none
shall also succeed.

ADD:  or if an edit-config with
default-operation=none references the container instance.

I feel the "none" case is not handled clearly enough yet.

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 4 Aug 2016 13:21:00 +0200

Rob,

> Does that mean that for an empty NP container, it would be up to the server to decide whether or not to evaluate the containers must/when statements?

That would be terrible. It must be completely clear when must statements are evaluated and when not.

>  But if the NP container exists due to existence of child nodes then the must/when statements would be guaranteed to be evaluated by the server?

I think there is no argument that must statements on NP containers MUST be evaluated when the container has child nodes. In my previous message, in the preceding text you didn't quote, I tried to explain why I think it's a bad idea to not also evaluate the must statements when the NP container is empty. In many real cases, it's not easy for a model reader to know whether the container has child nodes or not.

/jan

---

From: Robert Wilton <[email-masked]>
Date: Thu, 4 Aug 2016 13:27:57 +0100

Hi Jan,

> That would be terrible. It must be completely clear when must statements are evaluated and when not.
It can't be that terrible, doesn't YANG 1.0 manage today with this 
behaviour? :-)

I guess that my point is thus:  if a NP container's must/when condition 
should never consider/depend on the existence of said NP container, then 
for an empty NP container it should make no difference as to whether or 
not they they are evaluated by the device.

I question whether it is sensible to allow when/must statements on an NP 
container at all.  In many ways I would rather that they were restricted 
to only schema nodes that actually exist as datanodes, at least then the 
semantics are obvious, no special magic behaviour is required.

> I think there is no argument that must statements on NP containers MUST be evaluated when the container has child nodes. In my previous message, in the preceding text you didn't quote, I tried to explain why I think it's a bad idea to not also evaluate the must statements when the NP container is empty.

> In many real cases, it's not easy for a model reader to know whether the container has child nodes or not.
Yes.  I had read Phil's suggestion as: don't write must/when statements 
that depend on the existence of an NP container.  This sounds like quite 
sensible advise to me, but I might have misunderstood what he was 
suggesting.

Thanks,
Rob

---

From: William Ivory <[email-masked]>
Date: Thu, 4 Aug 2016 12:39:37 +0000

Hi Rob,

What about a must statement on a NP-container that implements mutual exclusivity with another node, eg the following when top is configured:

Container top {
	Container np1 {
		Must "not(../np2_leaf)";
		Leaf np1_leaf { type string; }
	}
	Container np2 {
		Leaf np2_leaf { type string; }
	}
}

At first glance, I think many people would assume this was intended to prevent both np1_leaf and np2_leaf being configured at the same time.  However, if we configure np2_leaf, container 'top' is configured, so we evaluate the must on np1 (as a np container child of an existing node, as per YANG 1.1 stated requirements) and the must statement evaluates to false.  Therefore we cannot configure np2_leaf *ever* in this case.

Now you could argue this is badly modelled YANG, but I would suggest it's decidedly non-obvious that np2_leaf is not configurable here.

Regards,

William

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Robert Wilton
Sent: 04 August 2016 13:28
To: Jan Lindblad <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

Hi Jan,

On 04/08/2016 12:21, Jan Lindblad wrote:
> Rob,
>
>>> Jan Lindblad writes:
>>>> I'm fine with this. Maybe we should clarify that must statements on 
>>>> NP containers are evaluated if the NP container parent exists. 
>>>> That's where the "always exists" notion might help understanding a bit.
>>> value, and must/when conditions should never consider or depend on 
>>> their existence.
It can't be that terrible, doesn't YANG 1.0 manage today with this behaviour? :-)

I guess that my point is thus:  if a NP container's must/when condition should never consider/depend on the existence of said NP container, then for an empty NP container it should make no difference as to whether or not they they are evaluated by the device.

I question whether it is sensible to allow when/must statements on an NP container at all.  In many ways I would rather that they were restricted to only schema nodes that actually exist as datanodes, at least then the semantics are obvious, no special magic behaviour is required.

> In many real cases, it's not easy for a model reader to know whether the container has child nodes or not.
Yes.  I had read Phil's suggestion as: don't write must/when statements that depend on the existence of an NP container.  This sounds like quite sensible advise to me, but I might have misunderstood what he was suggesting.

Thanks,
Rob

_______________________________________________
Netconf mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_u8ZrZ2Y&s=x12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=

---

From: Robert Wilton <[email-masked]>
Date: Thu, 4 Aug 2016 14:10:02 +0100

Hi William,

> Now you could argue this is badly modelled YANG, but I would suggest it's decidedly non-obvious that np2_leaf is not configurable here.
RW:

Yes, exactly.  This is why I don't like must statements on np 
containers.  Enforcing a constraint on an construct that doesn't 
properly exist is a bit odd :-)

I would suggest that it would be clearer to write this as:

Container top {
   Container np1 {
     Leaf np1_leaf {
       type string;
       must "not(../../np2_leaf)";
     }
   }
   Container np2 {
     Leaf np2_leaf {
       type string;
     }
   }
}

or perhaps:

Container top {
   Container np1 {
     Leaf np1_leaf {
       type string;
       must "not(../../np2_leaf)";
     }
   }
   Container np2 {
     Leaf np2_leaf {
       type string;
       must "not(../../np1_leaf)";
     }
   }
}

Thanks,
Rob

---

From: William Ivory <[email-masked]>
Date: Thu, 4 Aug 2016 13:27:42 +0000

So I quite agree that there are better ways of writing this.  However, my initial YANG is valid, and at first glance it is tempting to write it that way unless you have been following this discussion thread (-:

The YANG 1.1 behaviour gives what I think some (many?) would see as unexpected behaviour.  If treated as clarification for YANG 1.0 (ie it applies to YANG 1.0 retrospectively) then we could end up invalidating currently valid YANG 1.0 models if they have any examples like mine below.  Conversely, Jan's ownership-voucher example would become invalid if we don't take the YANG 1.1 behaviour and retrospectively apply it to YANG 1.0.

I'm also not convinced that only evaluating musts on NP containers to one level below configured nodes is consistent with how we deal with defaults and mandatory statements.  For those we examine all possible nodes, configured or otherwise, at any depth in the tree.  I think we should either never evaluate must statements on NP containers which have no children, or we should always evaluate them at any depth in the tree.  What's so special about those that are children of a configured node versus those that are grandchildren (or more)?

I would be interested to hear from those who have written YANG models (as opposed to those implementing YANG compilers) as to the perceived impact of the different options on your existing models.  Internally our YANG 1.0 models have been written on the assumption we do not evaluate musts on NP containers with no child nodes, but it would be reasonably easy to add 'not(current() or ...' to the front of any such must statements to render the outcome of this discussion irrelevant by ensuring the statements evaluate true when the NP container is not configured and thus effectively ignoring the constraint when not configured.

Regards,

William

-----Original Message-----
From: Robert Wilton [mailto:[email-masked]] 
Sent: 04 August 2016 14:10
To: William Ivory <[email-masked]>; Jan Lindblad <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

Hi William,

RW:

Yes, exactly.  This is why I don't like must statements on np containers.  Enforcing a constraint on an construct that doesn't properly exist is a bit odd :-)

Container top {
   Container np1 {
     Leaf np1_leaf {
       type string;

or perhaps:

Container top {
   Container np1 {
     Leaf np1_leaf {
       type string;

Thanks,
Rob

>>>>> I'm fine with this. Maybe we should clarify that must statements 
>>>>> on NP containers are evaluated if the NP container parent exists.
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_netconf&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_
> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_u
> 8ZrZ2Y&s=x12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=
> .
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Aug 2016 16:55:17 +0200

Jan Lindblad <[email-masked]> writes:

> [ Unknown signature status ]

I think the rules should be the same as for leaves with default values
that are in use (sec. 7.6.1). We could introduce the term "default
content" that includes leaf/leaf-list nodes with default values and
NP-containers.

An implication of this is that a must statement on an NP-container that
is inside the default case of a choice also applies, but that should be
OK.

Of course, another question is whether empty NP-containers are included
in server's responses or not, but this is IMO up to each protocol to
decide this.

Lada

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 04 Aug 2016 11:02:32 -0400

William Ivory <[email-masked]> writes:
> So I quite agree that there are better ways of writing this.  However,
> my initial YANG is valid, and at first glance it is tempting to write
> it that way unless you have been following this discussion thread (-:

That's true.  I'd say my thesis is that NP containers MUST NOT have must
statements, and any XPath expression MUST NOT test for the presence of
an NP container node.  (I think it might be desirable in some
circumstances to return it as a member of a result set, especially if
the XPath expression is attached to a descendant node.)

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 04 Aug 2016 11:03:52 -0400

>        must "not(../../np2_leaf)";

Should that be "not(../../np2/np2_leaf)", or can you can abbreviate
XPath by leaving out intermediate nodes?

Dale

---

From: Robert Wilton <[email-masked]>
Date: Thu, 4 Aug 2016 18:28:42 +0100

Hi Dale,

No, you are right, it should include the np2 container.

IIRC, Xpath does have syntax to allow layers to be missed out, perhaps 
something like "not(../..//np2_leaf)", although I don't know whether 
this format is allowed by YANG, and even if it was, I wouldn't be 
surprised if this unsupported by some YANG must/when statement 
processors because of the additional complexity and processing overhead.

Thanks,
Rob

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Aug 2016 14:18:34 -0400

>not they they are evaluated by the device.

And the natural outcome is that a "must"/"when" expression on an
NP container must always be validated without regard to the existence
of any NP container.

>semantics are obvious, no special magic behaviour is required.

If we take the position above, then it won't matter.  Sometimes
it's more convenient or meaningful (to the reader) to place conditions
on the container.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 4 Aug 2016 11:46:35 -0700

> it's more convenient or meaningful (to the reader) to place conditions
But the main use-case for must-stmt inside the container are for constraints
on the child nodes.  For lists and P-containers, this works fine.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 4 Aug 2016 19:11:02 -0400

>on the child nodes.  For lists and P-containers, this works fine.

Absolutely.  I'm advocating for allowing, not preventing, must/when
on NP containers, and that they be validated without regard to the
existence of the container.

container system {
   container services {
      container ssh {
         presense "Enable SSH";
         ...
      }
      container ssh-evil-twin {
         presense "Enable SSH's evil twin protocol";
         ...
      }
      must "ssh || ssh-evil-twin";
   }
}

This "must" constraint should be validated regardless of whether
[system] or [system services] appear in the database.  In the
end, one of [system services ssh] or [system services ssh-evil-twin]
must exist for the configuration to be valid.

Of course, the implementation may internally rewrite this to be a
top-level constraint of:

   must "system/services/ssh || system/services/ssh-evil-twin";

if that's more convenient to the implementation.  But to the reader,
having the constraint placed near the appropriate nodes is a win.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 5 Aug 2016 09:49:16 +0200

> On 05 Aug 2016, at 01:11, Phil Shafer <[email-masked]> wrote:
> 
> Andy Bierman writes:

And since we need them as the context node for such evaluations, it is IMO easier to assume that they are present in the (conceptual) datastore. The when statement, if present, needs to be evaluated as described in sec. 7.21.5, and if it evaluates to false, the NP-container should be considered absent - so that must statements aren't evaluated, if they are present. I think it is consistent, albeit somewhat complicated. 

> must exist for the configuration to be valid.

Yes (except that the above isn't a valid XPath expression).

Lada

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 5 Aug 2016 10:43:20 +0200

Hello,

As both a network node but also as a model writer: We avoid "must" on NP 
containers.  Or declare containers as presence just to avoid the risk.

Generally any YANG feature that is not defined clearly enough is avoided 
by us. Better do an "ugly" workaround then be surprised and face 
potentially backward incompatible changes to our models. I can live with 
a good YANG solution I can live with a bad YANG solution, I can not live 
with uncertainty.

Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 5 Aug 2016 10:50:39 +0200

> On 04 Aug 2016, at 15:27, William Ivory <[email-masked]> wrote:
> 
> I would be interested to hear from those who have written YANG models (as opposed to those implementing YANG compilers) as to the perceived impact of the different options on your existing models.  Internally our YANG 1.0 models have been written on the assumption we do not evaluate musts on NP containers with no child nodes, but it would be reasonably easy to add 'not(current() or ...' to the

This doesn't really work: in order to evaluate an XPath expression, the context node must exist, and in our case the context node is an instance of the NP-container. So "not(current())" by definition always evaluates to false.

Lada 

>  front of any such must statements to render the outcome of this discussion irrelevant by ensuring the statements evaluate true when the NP container is not configured and thus effectively ignoring the constraint when not configured.
> 
> Regards,
> 
> William
>

---

From: William Ivory <[email-masked]>
Date: Fri, 5 Aug 2016 09:01:47 +0000

Hi Balazs,

That is good practical advice for model writers.  However, it doesn't help anyone who is validating configuration against a YANG model as there you are not necessarily in control of the models presented to you.

William

-----Original Message-----
From: Balazs Lengyel [mailto:[email-masked]] 
Sent: 05 August 2016 09:43
To: William Ivory <[email-masked]>; Robert Wilton <[email-masked]>; Jan Lindblad <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

Hello,

As both a network node but also as a model writer: We avoid "must" on NP containers.  Or declare containers as presence just to avoid the risk.

Generally any YANG feature that is not defined clearly enough is avoided by us. Better do an "ugly" workaround then be surprised and face potentially backward incompatible changes to our models. I can live with a good YANG solution I can live with a bad YANG solution, I can not live with uncertainty.

Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 5 Aug 2016 11:03:19 +0200

> On 05 Aug 2016, at 10:43, Balazs Lengyel <[email-masked]> wrote:
> 
> Hello,
> 

I strongly disagree.

> Generally any YANG feature that is not defined clearly enough is avoided by us. Better do an "ugly" workaround then be surprised and face potentially backward incompatible changes to our models. I…

Perhaps 6020bis is not (yet) sufficently clear but IMO there is no uncertainty in what Jan and I proposed earlier:

1. Conceptual data tree may have some default contents: instances of leaf and leaf-list nodes with default values defined by the data   
   model, and NP-containers.

2. The rules that determine whether a given default instance is in use or not are exactly those specified in sec. 7.6.1:

"""
The usage of the default value depends on the leaf's closest ancestor node in the schema tree that is not a non-presence container (see Section 7.5.1):

   o  If no such ancestor exists in the schema tree, the default value
      MUST be used.

   o  Otherwise, if this ancestor is a case node, the default value MUST
      be used if any node from the case exists in the data tree, or if
      the case node is the choice's default case, and no nodes from any
      other case exist in the data tree.

   o  Otherwise, the default value MUST be used if the ancestor node
      exists in the data tree.

   In these cases, the default value is said to be in use.
"""

I believe that everything else follows from this and the current text of 6020bis.

Lada

---

From: William Ivory <[email-masked]>
Date: Fri, 5 Aug 2016 09:19:49 +0000

Hi Lada,

I was assuming that if a NP container had no children then from the perspective of current() it didn't exist, but that it was reasonable to evaluate the must expression on it as a 'virtual' node.  This just gets messier and messier, though I guess that 'count(*) = 0' (assuming no non-presence container children, otherwise would need to name children) would work instead?

There seem to be 3 options for evaluating must statements on NP containers that have no children - would appreciate others' input on this.  In addition, Balazs' suggestion that modellers avoid must statements on NP containers where possible would seem sensible advice!

(a) Never evaluate

Never evaluate a must statement on a non-presence container that has no children.

Pros:
- simple to understand
- reduces number of must statements to evaluate when validating configuration
- less likely to lead to unintended consequences of must statements being evaluated on nodes that don't appear in configuration

Cons:
- some existing models (in YANG 1.0 and presumably YANG 1.1) assume evaluation of must statements on NP container children of existing nodes as added / clarified in YANG 1.1
- need to confirm we can still model the likes of the ownership voucher must statement by altenative means if we adopt this interpretation

(b) Evaluate when parent exists

We evaluate must statements on non-presence container if their parent node is configured.

Pros:
- this is the stated position in YANG 1.1 (conflicting opinions exist on this alias as to whether it should be retrospectively applied to YANG 1.0 as 'clarification' or not)
- some existing models assume this is the case (eg Jan's ownership-voucher example (YANG 1.0 model))

Cons:
- may lead to unintended consequences of must statements being unexpectedly evaluated (albeit model writers *should* understand how it works once we have clarified it!)
- why only children, not grandchildren etc?  We examine mandatory and default on every single node, so why not for NP containers as well

(c) Always evaluate

We always evaluate must statements on non-presence containers

Pros:
- easy to understand this rule

Cons:
- this is different to both YANG 1.0 and YANG 1.1 current interpretation (whether you take the YANG 1.1 position as a change or as clarification on YANG 1.0)
- validation now has the overhead of evaluating ALL must statements on all NP containers even when not configured.

---

Regards,

William

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: 05 August 2016 09:51
To: William Ivory <[email-masked]>
Cc: Robert Wilton <[email-masked]>; Jan Lindblad <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [Netconf] What should a server response be? - depending on NP-containers

> I would be interested to hear from those who have written YANG models 
> (as opposed to those implementing YANG compilers) as to the perceived 
> impact of the different options on your existing models.  Internally 
> our YANG 1.0 models have been written on the assumption we do not 
> evaluate musts on NP containers with no child nodes, but it would be 
> reasonably easy to add 'not(current() or ...' to the

Lada 

>> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=751sECIaA5HaNM0wQdHxLvA6UwL5IhKW91y_
>> u 8ZrZ2Y&s=x12_Ko8id4YJBVF1rFmAvbKVrZCHdIHsFnzswwJ1k68&e=
>> .
>> 
> 
> man_listinfo_netconf&d=CwIFAg&c=IL_XqQWOjubgfqINi2jTzg&r=GByLeg9jZvOv_
> AlgBo9uvdDrxizlOR7l_SnTXowyJU8&m=6jlb0kQeoX8x29SUyoT8wXmmEAZeH2PaJOIXx
> ueVRP4&s=o-TUEWoTedxYQZ0UmLD-TX17raAc9Dz1VMLk78SnXdU&e=

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 5 Aug 2016 12:09:40 +0200

> On 05 Aug 2016, at 11:19, William Ivory <[email-masked]> wrote:
> 
> Hi Lada,
> 
> I was assuming that if a NP container had no children then from the perspective of current() it didn't exist, but that it was reasonable to evaluate the must expression on it as a 'virtual' node.  This just gets messier and messier, though I guess that

XPath spec requires a certain context, and we have to provide it because otherwise the evaluation may not be well defined. Pretending that the context node exists and doesn't exist at the same time seems weird, and IMO it's unnecessary - we can just assume the NP-container is present in the conceptual data tree, as we do, e.g., for leaves with default values.

> 'count(*) = 0' (assuming no non-presence container children, otherwise would need to name children) would work instead?

Right, for a non-existent NP-container that's in use, 'count(*) = 0' is true.

> There seem to be 3 options for evaluating must statements on NP containers that have no children - would appreciate others' input on this.  In addition, Balazs' suggestion that modellers avoid must…

I don't think so, an NP-container may be a good place for specifying semantics constrains for its children. I have used it in my modules several times.

> (b) Evaluate when parent exists

I support this one, except that it's not every parent that's counts. I wrote down the exact rules in my response to Balazs.

> - may lead to unintended consequences of must statements being unexpectedly evaluated (albeit model writers *should* understand how it works once we have clarified it!)

Model writers shouldn't be surprised if it is clearly stated in the spec, otherwise they could also be surprised by must statements being unexpectedly evaluated on default leaves or leaf-lists. 

> - why only children, not grandchildren etc?  We examine mandatory and default on every single node, so why not for NP containers as well

My rules work for grandchildren, too, because it is the ancestor node that is not a non-presence container that has to be present (see sec. 7.6.1 in 6020bis).

Cheers, Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 5 Aug 2016 13:31:59 +0200

> On 05 Aug 2016, at 12:09, Ladislav Lhotka <[email-masked]> wrote:
> 
>> 

Actually, this won't be true if the NP-container has another NP-container as its child. Sorry for the confusion.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Fri, 5 Aug 2016 07:57:42 -0400

>Yes (except that the above isn't a valid XPath expression).

Doh!  Mine allows this (and "&&" and "=="), since old fingers are
hard to retrain, and the single equals makes a very bad habit.
And we can rewrite them in standard xpath as we export them.

Thanks,
 Phil

---

From: Robert Wilton <[email-masked]>
Date: Fri, 5 Aug 2016 14:57:54 +0100

Hi William,

Pragmatically, I think that I would also go for (b), with the fix 
suggested by Lada.

My reasoning is that despite not liking "when"/"must" statements on 
np-containers they are clearly useful in some cases and cannot be banned 
outright.

I also like Phil's explanation that a server could effectively rewrite 
the paths in the xpath so the "when"/"must" statement is effectively 
bound to the nearest parent container that has presence.  That almost 
seems like a better way of thinking about what they really are.

Thanks,
Rob

---

From: Vladimir Vassilev <[email-masked]>
Date: Fri, 05 Aug 2016 20:18:34 +0200

Hello,

The proposed changes must take into account the implications on existing 
models and extensions. I can think of NACM  for example where in some 
use-cases NP containers are used to grant update (but not create) rights 
to user groups. It is absolutely legal to configure "update" rights to 
/interfaces to a group of users reserving the "create" right to the 
superuser. How is this scenario handled by servers ignoring empty 
non-presence containers?

I personally do not like the YANG 1.1 auto evaluation of child NP 
containers text. The example of William Ivory from 08/04/2016 02:39 PM 
with the 2 mutually exclusive containers which is impossible in YANG 1.1 
is one of the precedents.

Vladimir

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Aug 2016 14:23:10 -0700

Hi,

I am quite willing to accept the existing design in YANG 1.1 that NP
containers
are considered to be present if there is a non-NP ancestor present (or the
NP container is a top-level data node).  This is easier to support.
It matches the top-down callback design of many server implementations.

The update rules in sec 11 of 6020bis do not cover NP-containers correctly.
It should be illegal to add a mandatory NP-container as a child node
to the augment target.

This needs to include must-stmt (fixed in the term "mandatory node", bullet
3)
I don't think the text below is quite right.  I suspect Lada can do better.

OLD:

sec 3.

   o  mandatory node: A mandatory node is one of:

      *  A leaf, choice, anydata, or anyxml node with a "mandatory"
         statement with the value "true".

      *  A list or leaf-list node with a "min-elements" statement with a
         value greater than zero.

      *  A container node without a "presence" statement and which has
         at least one mandatory node as a child.

NEW:

  o  mandatory node: A mandatory node is one of:

      *  A leaf, choice, anydata, or anyxml node with a "mandatory"
         statement with the value "true".

      *  A list or leaf-list node with a "min-elements" statement with a
         value greater than zero.

      *  A container node without a "presence" statement and which has
         at least one mandatory node as a child, or has a "must" statement
         that will evaluate to "false" if the container has no child node
instances.

Andy

On Fri, Aug 5, 2016 at 6:57 AM, Robert Wilton <[email-masked]> wrote:

> I also like Phil's explanation that a server could effectively rewrite the
> paths in the xpath so the "when"/"must" statement is effectively bound to
> the nearest parent container that has presence.  That almost seems like a
> better way of thinking about what they really are.
>
> Thanks,
> Rob
>
>
>> I was assuming that if a NP container had no children then from the
>> perspective of current() it didn't exist, but that it was reasonable to
>> evaluate the must expression on it as a 'virtual' node.  This just gets
>> messier and messier, though I guess that 'count(*) = 0' (assuming no
>> non-presence container children, otherwise would need to name children)
>> would work instead?
>>
>> There seem to be 3 options for evaluating must statements on NP
>> containers that have no children - would appreciate others' input on this.
>> In addition, Balazs' suggestion that modellers avoid must statements on NP
>> containers where possible would seem sensible advice!
>>
>> (a) Never evaluate
>>
>> - less likely to lead to unintended consequences of must statements being
>> evaluated on nodes that don't appear in configuration
>>
>> Cons:
>> - some existing models (in YANG 1.0 and presumably YANG 1.1) assume
>> evaluation of must statements on NP container children of existing nodes as
>> added / clarified in YANG 1.1
>> - need to confirm we can still model the likes of the ownership voucher
>> must statement by altenative means if we adopt this interpretation
>>
>> - this is the stated position in YANG 1.1 (conflicting opinions exist on
>> this alias as to whether it should be retrospectively applied to YANG 1.0
>> as 'clarification' or not)
>> - some existing models assume this is the case (eg Jan's
>> ownership-voucher example (YANG 1.0 model))
>>
>> Cons:
>> - may lead to unintended consequences of must statements being
>> unexpectedly evaluated (albeit model writers *should* understand how it
>> works once we have clarified it!)
>> - why only children, not grandchildren etc?  We examine mandatory and
>> default on every single node, so why not for NP containers as well
>>
>> (c) Always evaluate
>>
>> - this is different to both YANG 1.0 and YANG 1.1 current interpretation
>> (whether you take the YANG 1.1 position as a change or as clarification on
>> YANG 1.0)
>> - validation now has the overhead of evaluating ALL must statements on
>> all NP containers even when not configured.
>>
>> ---
>>
>> Regards,
>>
>> William
>>
>>> my initial YANG is valid, and at first glance it is tempting to write it
>>> that way unless you have been following this discussion thread (-:
>>>
>>> The YANG 1.1 behaviour gives what I think some (many?) would see as
>>> unexpected behaviour.  If treated as clarification for YANG 1.0 (ie it
>>> applies to YANG 1.0 retrospectively) then we could end up invalidating
>>> currently valid YANG 1.0 models if they have any examples like mine below.
>>> Conversely, Jan's ownership-voucher example would become invalid if we
>>> don't take the YANG 1.1 behaviour and retrospectively apply it to YANG 1.0.
>>>
>>> I'm also not convinced that only evaluating musts on NP containers to
>>> one level below configured nodes is consistent with how we deal with
>>> defaults and mandatory statements.  For those we examine all possible
>>> nodes, configured or otherwise, at any depth in the tree.  I think we
>>> should either never evaluate must statements on NP containers which have no
>>> children, or we should always evaluate them at any depth in the tree.
>>> What's so special about those that are children of a configured node versus
>>> those that are grandchildren (or more)?
>>>
>> This doesn't really work: in order to evaluate an XPath expression, the
>> context node must exist, and in our case the context node is an instance of
>> the NP-container. So "not(current())" by definition always evaluates to
>> false.
>>
>> Lada
>>
>>   front of any such must statements to render the outcome of this
>>> discussion irrelevant by ensuring the statements evaluate true when the NP
>>> container is not configured and thus effectively ignoring the constraint
>>> when not configured.
>>>
>>> Regards,
>>>
>>> William
>>>
>>>> What about a must statement on a NP-container that implements mutual
>>>> exclusivity with another node, eg the following when top is configured:
>>>>
>>>> Container top {
>>>>         Container np1 {
>>>>                 Must "not(../np2_leaf)";
>>>> At first glance, I think many people would assume this was intended to
>>>> prevent both np1_leaf and np2_leaf being configured at the same time.
>>>> However, if we configure np2_leaf, container 'top' is configured, so we
>>>> evaluate the must on np1 (as a np container child of an existing node, as
>>>> per YANG 1.1 stated requirements) and the must statement evaluates to
>>>> false.  Therefore we cannot configure np2_leaf *ever* in this case.
>>>>
>>>> Now you could argue this is badly modelled YANG, but I would suggest
>>>> it's decidedly non-obvious that np2_leaf is not configurable here.
>>>>
>>> RW:
>>>
>>>>>> statements?
>>>> for an empty NP container it should make no difference as to whether or not
>>>> they they are evaluated by the device.
>>>>
>>>> I question whether it is sensible to allow when/must statements on an
>>>> NP container at all.  In many ways I would rather that they were restricted
>>>>    But if the NP container exists due to existence of child nodes then
>>>>>> the must/when statements would be guaranteed to be evaluated by the server?
>>>>>>
>>>>> I think there is no argument that must statements on NP containers
>>>>> MUST be evaluated when the container has child nodes. In my previous
>>>>> message, in the preceding text you didn't quote, I tried to explain why I
>>>>> think it's a bad idea to not also evaluate the must statements when the NP
>>>>> container is empty.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 10 Aug 2016 18:50:52 -0700

> On Aug 10, 2016, at 2:23 PM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> I am quite willing to accept the existing design in YANG 1.1 that NP containers
> This needs to include must-stmt (fixed in the term "mandatory node", bullet 3)
>          that will evaluate to "false" if the container has no child node instances.

A slight modification to the third bullet.

OLD:

      *  A container node without a "presence" statement and which has
         at least one mandatory node as a child, or has a "must" statement
         that will evaluate to "false" if the container has no child node instances.

NEW:

      *  A container node without a "presence" statement and which has
         at least one mandatory node as a child, or has a "must" statement
         that will evaluate to “true" if the container has default nodes as defined
         for leafs (section 7.6.1) or for leaf-list (section 7.7.2).

> 
> 
> 
> Andy
> 
> 
> 
> 
> 
> On Fri, Aug 5, 2016 at 6:57 AM, Robert Wilton <[email-masked] <mailto:[email-masked]>> wrote:
> Hi William,
> 
> Pragmatically, I think that I would also go for (b), with the fix suggested by Lada.
> 
> My reasoning is that despite not liking "when"/"must" statements on np-containers they are clearly useful in some cases and cannot be banned outright.
> 
> I also like Phil's explanation that a server could effectively rewrite the paths in the xpath so the "when"/"must" statement is effectively bound to the nearest parent container that has presence.  That almost seems like a better way of thinking about what they really are.
> 
> Thanks,
> Rob
> 
> 
> From: Ladislav Lhotka [mailto:[email-masked] <mailto:[email-masked]>]
> Cc: Robert Wilton <[email-masked] <mailto:[email-masked]>>; Jan Lindblad <[email-masked] <mailto:[email-masked]>>; Netconf <[email-masked] <mailto:[email-masked]>>
> From: Robert Wilton [mailto:[email-masked] <mailto:[email-masked]>]
> To: William Ivory <[email-masked]>; Jan Lindblad <[email-masked] <mailto:[email-masked]>>
> From: Netconf [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Robert
> Wilton
> To: Jan Lindblad <[email-masked] <mailto:[email-masked]>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai>
> l
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail>

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Aug 2016 19:08:59 -0700

>          for leafs (section 7.6.1) or for leaf-list (section 7.7.2).

It is "false" must-stmts that cause a problem.

e.g.:

augment /foo:/top {
   container okay {
      must "A >= 1 and B >= A";
      leaf A { type int32; default 1;  }
      leaf B { type int32; default 2;  }
  }
}

We want to prevent an augment with a mandatory NP-container
where only the augmented parent exists, causing the must-stmt
to be evaluated as false, causing the creation of the parent node to fail.
This is not allowed for augment (just in-line NP containers in the first
release)

augment /foo:/top {
   container not-okay {
      must "A >= 1 and B >= A";
      leaf A { type int32; }
      leaf B { type int32; }
  }
}

>> the paths in the xpath so the "when"/"must" statement is effectively bound
>> to the nearest parent container that has presence.  That almost seems like
>> a better way of thinking about what they really are.
>>
>> Thanks,
>> Rob
>>
>>
>>> - less likely to lead to unintended consequences of must statements
>>> being evaluated on nodes that don't appear in configuration
>>>
>>> Cons:
>>> To: William Ivory <[email-masked] <[email-masked]>>
>>> On 04 Aug 2016, at 15:27, William Ivory <[email-masked]
>>>> <[email-masked]>> wrote:
>>>>
>>>> To: William Ivory <[email-masked] <[email-masked]>>; Jan
>>>> Lindblad <[email-masked]>
>>>>> I guess that my point is thus:  if a NP container's must/when
>>>>> condition should never consider/depend on the existence of said NP
>>>>> container, then for an empty NP container it should make no difference as
>>>>> to whether or not they they are evaluated by the device.
>>>>>
>>>>> Yes.  I had read Phil's suggestion as: don't write must/when
>>>>> statements that depend on the existence of an NP container.  This sounds
>>>>> like quite sensible advise to me, but I might have misunderstood what he
>>>>> was suggesting.
>>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>> /jan
>>>>>>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Aug 2016 10:00:52 +0200

>          that will evaluate to "false" if the container has no child node

I don't agree with this, "must" statements on leaf(-list) default
instances are also evaluated but it doesn't make them mandatory.

As I wrote, IMO the easiest solution is to add NP-containers to default
content, subject to the same rules as we have for leaf(-list)s with
defaults.

I'd suggest to wait for Martin, hopefully he isn't shipwrecked on a
deserted island.

Lada

---

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 11 Aug 2016 14:36:14 +0200

On 08/11/2016 10:00 AM, Ladislav Lhotka wrote:
> deserted island. Lada
+1

Because Martin knows why the following text was introduced between rev. 
01 and rev. 02  in 6.4.1 Xpath Context:

I can't find nothing relevant to the change on the mailing list and the 
minutes in that time period, or the issue list.

IMO the solution is to accept that both presence and non-presence 
containers are explicitly created and deleted. This would allow the 
following patch to rfc6020.txt as a starting point and yield this 
discussion pointless. In the same time it would fix the conflict with 
NACM in the cases when non-presence container are used to organize 
access rights which is often the only sane way to do it.

Incremental editing of configuration trees is another feature e.g. you 
would hate operating system that does not allow you the creation of 
empty directories or automatically creates them for you just because 
they do not contain a file. And we accept to live with the overhead of 
empty directories for various reasons ... like access control etc. In 
the end this is what has started the entire problem.

567,569d566
<    o  A container node without a "presence" statement, which has at
<       least one mandatory node as a child.
<
2875,2877c2872
<    and to keep these nodes together.  The "scrambling" node itself has
<    no meaning, so removing the node when it becomes empty relieves the
<    user from performing this task.
---
 >    and to keep these nodes together.
2882,2883c2877
<    organizing related configuration.  These containers are explicitly
<    created and deleted.
---
 >    organizing related configuration.
3118,3124d3111
<    A NETCONF server that replies to a <get> or <get-config> request MAY
<    choose not to send a container element if the container node does not
<    have the "presence" statement and no child nodes exist. Thus, a
<    client that receives an <rpc-reply> for a <get> or <get-config>
<    request, must be prepared to handle the case that a container node
<    without a "presence" statement is not present in the XML.
<
3131,3133d3117
<    If a container does not have a "presence" statement and the last
<    child node is deleted, the NETCONF server MAY delete the container.
<
3235,3236c3219
<    depends on the leaf's closest ancestor node in the schema tree that
<    is not a non-presence container:
---
 >    depends on the leaf's closest ancestor node in the schema tree:
3321,3322c3304,3305
<    the type of the leaf's closest ancestor node in the schema tree that
<    is not a non-presence container (see Section 7.5.1):
---
 >    the type of the leaf's closest ancestor node in the schema tree
 >    (see Section 7.5.1):
3509,3510c3492
<    or list's closest ancestor node in the schema tree that is not a non-
<    presence container (see Section 7.5.1):
---
 >    or list's closest ancestor node in the schema tree (see Section 
7.5.1):
4385,4386c4367
<    closest ancestor node in the schema tree which is not a non-presence
<    container (see Section 7.5.1):
---
 >    closest ancestor node in the schema tree (see Section 7.5.1):

Vladimir

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 11 Aug 2016 16:34:24 +0200

As I remember the discussion was started because netconf
default-operation=none  works in an unstable way on NP-containers.

The RFCs allows the sequence which some implementations do use:

edit-config operation=create empty NP-container

server deletes  the empty NP-container

client uses edit-config default-operation=none on NP-container
with operation=create to create a child node of the NP-container

server rejects the edit-config as the NP-container does not
exist, although the user explicitly created it.

This makes default-operation=none unusable. This is a MAJOR
problem for us, so we need a solution for this BUG.

regards Balazs

On 2016-08-11 14:36, Vladimir Vassilev
wrote:

On
08/11/2016 10:00 AM, Ladislav Lhotka wrote:

I'd suggest to wait for Martin, hopefully
he isn't shipwrecked on a deserted island. Lada

+1

Because Martin knows why the following text was introduced between
rev. 01 and rev. 02  in 6.4.1 Xpath Context:

container as a child, then the non-presence container also
exists in

the tree.

I can't find nothing relevant to the change on the mailing list
and the minutes in that time period, or the issue list.

IMO the solution is to accept that both presence and non-presence
containers are explicitly created and deleted. This would allow
the following patch to rfc6020.txt as a starting point and yield
this discussion pointless. In the same time it would fix the
conflict with NACM in the cases when non-presence container are
used to organize access rights which is often the only sane way to
do it.

Incremental editing of configuration trees is another feature e.g.
you would hate operating system that does not allow you the
creation of empty directories or automatically creates them for
you just because they do not contain a file. And we accept to live
with the overhead of empty directories for various reasons ...
like access control etc. In the end this is what has started the
entire problem.

567,569d566

<    o  A container node without a "presence" statement, which
has at

<

2875,2877c2872

<    and to keep these nodes together.  The "scrambling" node
itself has

<    no meaning, so removing the node when it becomes empty
relieves the

---

2882,2883c2877

<    organizing related configuration.  These containers are
explicitly

<    created and deleted.

---

3118,3124d3111

<    A NETCONF server that replies to a <get> or
<get-config> request MAY

<    choose not to send a container element if the container
node does not

<    have the "presence" statement and no child nodes exist.
Thus, a

<    client that receives an <rpc-reply> for a
<get> or <get-config>

<    request, must be prepared to handle the case that a
container node

<

3131,3133d3117

<    If a container does not have a "presence" statement and
the last

<    child node is deleted, the NETCONF server MAY delete the
container.

<

3235,3236c3219

<    depends on the leaf's closest ancestor node in the schema
tree that

---

3321,3322c3304,3305

<    the type of the leaf's closest ancestor node in the schema
tree that

---

3509,3510c3492

<    or list's closest ancestor node in the schema tree that is
not a non-

---

>    or list's closest ancestor node in the schema tree (see
Section 7.5.1):

4385,4386c4367

<    closest ancestor node in the schema tree which is not a
non-presence

---

Vladimir

Netconf mailing list

[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 11 Aug 2016 07:38:13 -0700

On Thu, Aug 11, 2016 at 7:34 AM, Balazs Lengyel <[email-masked]

>    - edit-config operation=create empty NP-container
>    - server deletes  the empty NP-container
>    - client uses edit-config default-operation=none on NP-container with
>    operation=create to create a child node of the NP-container
>    - server rejects the edit-config as the NP-container does not exist,
>    although the user explicitly created it.
>
> This makes default-operation=none unusable. This is a MAJOR problem for
> us, so we need a solution for this BUG.
>

This is not a bug.

You can place an nc:operation="merge" attribute in your edit request and
make it work.
In fact, default-operation="none" cannot possibly do anything unless you
put the
nc:operation attribute in the payload at the proper node.

Andy

>
> On 2016-08-11 14:36, Vladimir Vassilev wrote:
>
> Because Martin knows why the following text was introduced between rev. 01
> and rev. 02  in 6.4.1 Xpath Context:
>
> discussion pointless. In the same time it would fix the conflict with NACM
> in the cases when non-presence container are used to organize access rights
> which is often the only sane way to do it.
>
> would hate operating system that does not allow you the creation of empty
> directories or automatically creates them for you just because they do not
> contain a file. And we accept to live with the overhead of empty
> directories for various reasons ... like access control etc. In the end
> this is what has started the entire problem.
>
> 567,569d566

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 11 Aug 2016 17:07:14 +0200

Andy you can find the very first mail of the thread at

https://www.ietf.org/mail-archive/web/netconf/current/msg11438.html

Also the same example with a bit more detail:

container npCont {
leaf foo {}
}

1st request:
<edit-config>
<config>
<npCont/>
</config>
</edit-config>

Result=OK
The server creates npCont and later removes it (or maybe it does not even create it as it is empty)

2nd request:
<edit-config>
<default-operation>none</default-operation>
<config>
<npCont>
<foo operation="create">27</foo>
</npCont>
</config>
</edit-config>

Result=Error as npCont does not exist.

Saying: "don't use none because it is buggy, use merge instead"
is not nice. Also as I have described in earlier mails using
default-operation=merge can lead to accidentally creating
data-nodes. So the BUG around default-operation=none was the
starting point and is still a major issue.

regards Balazs

On 2016-08-11 16:38, Andy Bierman
wrote:

On Thu, Aug 11, 2016 at 7:34 AM,
Balazs Lengyel <[email-masked]>
wrote:

As I remember the discussion was started because
netconf default-operation=none  works in an unstable
way on NP-containers.

The RFCs allows the sequence which some
implementations do use:

client uses edit-config default-operation=none on
NP-container with operation=create to create a child
node of the NP-container

server rejects the edit-config as the NP-container
does not exist, although the user explicitly created
it.

This makes default-operation=none unusable. This is a
MAJOR problem for us, so we need a solution for this
BUG.

This is not a bug.

You can place an nc:operation="merge" attribute in your
edit request and make it work.

In fact, default-operation="none" cannot possibly do
anything unless you put the

nc:operation attribute in the payload at the proper
node.

regards Balazs

Andy

On 08/11/2016 10:00 AM, Ladislav
Lhotka wrote:

I'd suggest to wait for
Martin, hopefully he isn't shipwrecked on a deserted
island. Lada

+1

Because Martin knows why the following text was
introduced between rev. 01 and rev. 02  in 6.4.1 Xpath
Context:

If a node that exists in the accessible tree has a
non-presence

container as a child, then the non-presence
container also exists in

the tree.

I can't find nothing relevant to the change on the
mailing list and the minutes in that time period, or
the issue list.

IMO the solution is to accept that both presence and
non-presence containers are explicitly created and
deleted. This would allow the following patch to
rfc6020.txt as a starting point and yield this
discussion pointless. In the same time it would fix
the conflict with NACM in the cases when non-presence
container are used to organize access rights which is
often the only sane way to do it.

Incremental editing of configuration trees is another
feature e.g. you would hate operating system that does
not allow you the creation of empty directories or
automatically creates them for you just because they
do not contain a file. And we accept to live with the
overhead of empty directories for various reasons ...
like access control etc. In the end this is what has
started the entire problem.

567,569d566

<    o  A container node without a "presence"
statement, which has at

<

2875,2877c2872

<    and to keep these nodes together.  The
"scrambling" node itself has

<    no meaning, so removing the node when it
becomes empty relieves the

---

2882,2883c2877

<    organizing related configuration.  These
containers are explicitly

<    created and deleted.

---

3118,3124d3111

<    A NETCONF server that replies to a <get>
or <get-config> request MAY

<    choose not to send a container element if the
container node does not

<    have the "presence" statement and no child
nodes exist. Thus, a

<    client that receives an <rpc-reply> for
a <get> or <get-config>

<    request, must be prepared to handle the case
that a container node

<    without a "presence" statement is not present
in the XML.

<

3131,3133d3117

<    If a container does not have a "presence"
statement and the last

<    child node is deleted, the NETCONF server MAY
delete the container.

<

3235,3236c3219

<    depends on the leaf's closest ancestor node in
the schema tree that

---

3321,3322c3304,3305

<    the type of the leaf's closest ancestor node
in the schema tree that

<    is not a non-presence container (see Section
7.5.1):

---

3509,3510c3492

<    or list's closest ancestor node in the schema
tree that is not a non-

---

>    or list's closest ancestor node in the schema
tree (see Section 7.5.1):

4385,4386c4367

<    closest ancestor node in the schema tree which
is not a non-presence

---

Vladimir

Netconf mailing list

[email-masked]

---

From: Vladimir Vassilev <[email-masked]>
Date: Thu, 11 Aug 2016 17:22:11 +0200

On 08/11/2016 04:34 PM, Balazs Lengyel wrote:
>   * edit-config operation=create empty NP-container
>   * server deletes  the empty NP-container
>   * client uses edit-config default-operation=none on NP-container
>   * server rejects the edit-config as the NP-container does not exist,
> This makes default-operation=none unusable. This is a MAJOR problem 
> for us, so we need a solution for this BUG.
>
Right. Do you agree the patch I propose which removes the 
differentiation between presence and non-presence containers in terms of 
the requirement to explicitly create and delete them is a better 
solution then building on top of the problem simply to save bandwidth in 
case sloppy users create empty non-presence containers not used as 
instance identifier targets in NACM? Can someone explain why this is bad 
and instead we need kilobytes of clarifications and breaking backwards 
compatibility of the validation statements, NACM, iterative 
configuration editing etc. in YANG 1.1?

>> I can't find nothing relevant to the change on the mailing list and 
>> the minutes in that time period, or the issue list.
>>
>> you would hate operating system that does not allow you the creation 
>> of empty directories or automatically creates them for you just 
>> because they do not contain a file. And we accept to live with the 
>> overhead of empty directories for various reasons ... like access 
>> control etc. In the end this is what has started the entire problem.
>>
>> 567,569d566
> Mobile: +36-70-330-7909              email:[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Aug 2016 17:15:33 +0200

On Thu, Aug 11, 2016 at 05:07:14PM +0200, Balazs Lengyel wrote:
>    Saying: "don't use none because it is buggy, use merge instead" is not
>    nice. Also as I have described in earlier mails using
>    default-operation=merge can lead to accidentally creating data-nodes. So
>    the BUG around default-operation=none was the starting point and is still
>    a major issue.
>

If you add operation="merge" on npCont, does this not work around the
problem while being robust against accidentally creating data nodes?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 11 Aug 2016 17:25:24 +0200

> On 11 Aug 2016, at 16:34, Balazs Lengyel <[email-masked]> wrote:
> 
> As I remember the discussion was started because netconf default-operation=none  works in an unstable way on NP-containers.
> 
> 	• edit-config operation=create empty NP-container
> 	• server deletes  the empty NP-container
> 	• client uses edit-config default-operation=none on NP-container with operation=create to create a child node of the NP-container
> 	• server rejects the edit-config as the NP-container does not exist, although the user explicitly created it.

IMO this should succeed, and it could also succeed even without the first two steps.

What is the result if the NP-container happens to contain another leaf with a default value specified in the data model, but this leaf hasn't been explicitly configured?

Lada

> This makes default-operation=none unusable. This is a MAJOR problem for us, so we need a solution for this BUG.
> regards Balazs
> 
>>> I'd suggest to wait for Martin, hopefully he isn't shipwrecked on a deserted island. Lada 
>> +1 
>> 
>> Because Martin knows why the following text was introduced between rev. 01 and rev. 02  in 6.4.1 Xpath Context: 
>> 
>> I can't find nothing relevant to the change on the mailing list and the minutes in that time period, or the issue list. 
>> 
>> IMO the solution is to accept that both presence and non-presence containers are explicitly created and deleted. This would allow the following patch to rfc6020.txt as a starting point and yield this discussion pointless. In the same time it would fix the conflict with NACM in the cases when non-presence container are used to organize access rights which is often the only sane way to do it. 
>> 
>> Incremental editing of configuration trees is another feature e.g. you would hate operating system that does not allow you the creation of empty directories or automatically creates them for you just because they do not contain a file. And we accept to live with the overhead of empty directories for various reasons ... like access control etc. In the end this is what has started the entire problem. 
>> 
>> 567,569d566 
>> >    or list's closest ancestor node in the schema tree (see Section 7.5.1): 
>> 4385,4386c4367

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Aug 2016 10:28:21 +0200 (CEST)

> the minutes in that time period, or the issue list.

This is issue #41.

[it seems the link to the issues list doesn't work anymore.  so see
https://trac.tools.ietf.org/wg/netmod/trac/browser/yang-1.1/issues.txt]

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 17 Aug 2016 11:13:43 +0200 (CEST)

Hi,

I have read this long ML thread twice now, and I agree with Andy that:

1)  We should not / cannot make design changes in an errata or late in
    AUTH48; in order to do this we need to pull the document back to
    the WG and reach (rough) consensus on the behavior (note btw that
    this thread is currently in NETCONF, it really should be NETMOD).

2)  Since servers MAY delete NP-containers in some cases, clients can
    easily handle NP-containers by using "merge" on them.

I also agree with Jason that ideally the server should never fail on
any kind of operation on an NP-container, regardless of current state
and requested operation.  (But again, this is not a simple
clarification of the current text.)

And to answer the original question, I think the server that first got
a request to create the empty NP-containers and then a request w/
operation "none" is not correct when it fails with a "data-missing"
error.  There is no text in 6241 or 6020 that supports this behavior.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Aug 2016 11:37:33 +0200

> On 17 Aug 2016, at 10:28, Martin Bjorklund <[email-masked]> wrote:
> 

It was reflected in 6020bis in sec. 6.4.1:

I think for XPath evaluation this is sufficient, and it also addresses NP-containers inside NP-containers.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 17 Aug 2016 11:45:01 +0200

> On 17 Aug 2016, at 11:13, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

Agreed. Moreover, other documents have it as a normative reference.

> clarification of the current text.)

And it belongs to protocol specification anyway.

Lada

---

From: Phil Shafer <[email-masked]>
Date: Wed, 17 Aug 2016 11:31:03 -0400

>clarification of the current text.)

It really feels like this _is_ a clarification.  We're saying what
an implementation does to behave in a meaningful and consistent
way.  It's not a significant chance, but something that should have
been more clear in the original.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Aug 2016 08:44:47 -0700

> been more clear in the original.
I do not agree this is a clarification.
The behavior that makes the most sense is for the
server to NEVER change what the client did (e.g. deleting
the empty NP-container) in the first place.

If the server follows this rule then the client always gets what it expects.
The client can also choose to use "merge" and "remove" and then
all problems with NP-containers also go away.

RFC 6241 does not have any text at all that would even slightly
suggest that all operations on NP containers should always succeed.

The NETCONF WG would need to create NETCONF 1.2 that
had this behavior, because NETCONF 1.1 does not.
IMO this is not needed because there are existing workarounds.

Thanks,

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 17 Aug 2016 11:50:07 -0400

For example, the set of scrambling options for Synchronous Optical
   Network (SONET) interfaces may be placed inside a "scrambling"
   container to enhance the organization of the configuration hierarchy,
   and to keep these nodes together.  The "scrambling" node itself has
   no meaning, so removing the node when it becomes empty relieves the
   user from performing this task.

   In the second style, the presence of the container itself is
   configuration data, representing a single bit of configuration data.
   The container acts as both a configuration knob and a means of
   organizing related configuration.  These containers are explicitly
   created and deleted.

One can infer that since the second style are explicitly created
and deleted, the first style are implicitly created and deleted.

It seems awkward to say "the client must take particular care in
creating containers that have no real meaning".   The opposite
of the Postel Principle.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Aug 2016 09:08:57 -0700

> creating containers that have no real meaning".   The opposite

But NETCONF already thought of this problem.
It is no different than each server treating defaults differently.
The "merge" and "remove" operations are designed for this exact purpose.
The "create" and "delete" operations were not.

Thanks,

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 17 Aug 2016 09:47:22 -0700

On Wed, Aug 17, 2016 at 8:50 AM, Phil Shafer <[email-masked]> wrote:

> *These containers are explicitly    created and deleted.*
>

No -- I do not see that the text says anything about create and delete
operations in NETCONF.  This section in YANG 1.1 is not even marked
as <edit-config> in NETCONF like the others.

But if that text is supposed to mean that NP containers are not
explicitly created and deleted, then this text in 7.5.8 is wrong:

This text is explicitly referring to creating and deleting NP container
nodes,
and it contradicts the implied text you cited.

Andy

---

From: "Xiang Li" <[email-masked]>
Date: Wed, 17 Aug 2016 11:48:04 -0500

Hi

> From: Netconf [mailto:[email-masked]] On Behalf Of Phil Shafer
> Sent: Wednesday, August 17, 2016 10:50 AM
> To: Andy Bierman <[email-masked]>
> >RFC 6241 does not have any text at all that would even slightly suggest
> >that all operations on NP containers should always succeed.
> 
> One can infer that since the second style are explicitly created and
deleted,
> the first style are implicitly created and deleted.

I agree with this interpretation.
But current RFC6020bis: Section 7.5.8 clearly suggests that both NP and P
containers
can be manipulated explicitly, except that "If a container does not 
have a "presence" statement and the last child node is deleted, the NETCONF 
server MAY delete the container."

RFC6020bis:
----------------------------------------------------------------------------
---------------
7.5.8.  NETCONF <edit-config> Operations

   Containers can be created, deleted, replaced, and modified through
   <edit-config>, by using the "operation" attribute (see [RFC6241],
   Section 7.2) in the container's XML element.

When a NETCONF server processes an <edit-config> request, the
   elements of procedure for the container node are:

      If the operation is "merge" or "replace", the node is created if
      it does not exist.

      If the operation is "create", the node is created if it does not
      exist.  If the node already exists, a "data-exists" error is
      returned.

      If the operation is "delete", the node is deleted if it exists.
      If the node does not exist, a "data-missing" error is returned.

----------------------------------------------------------------------------
-------------

I think if this paragraph instead says:

----------------------------------------------------------------------------
-------------
7.5.8.  NETCONF <edit-config> Operations

 Containers with a "presence" statement can be created, deleted, replaced, 
and modified through <edit-config>, by using the "operation" attribute (see
[RFC6241],
   Section 7.2) in the container's XML element.

When a NETCONF server processes an <edit-config> request, the
   elements of procedure for the container node with a "presence" statement
are:

      If the operation is "merge" or "replace", the node is created if
      it does not exist.

      If the operation is "create", the node is created if it does not
      exist.  If the node already exists, a "data-exists" error is
      returned.

      If the operation is "delete", the node is deleted if it exists.
      If the node does not exist, a "data-missing" error is returned.

Containers without a "presence" statement are merely structural nodes, and
are
 implicitly created and deleted by the server. 

If a container does not have a "presence" statement, it is created
implicitly 
 along with creating any of its child nodes. If  the last child node of such
a container 
is deleted, the NETCONF server MAY delete the container.

Creating, replacing or deleting a container without a "presence" statement
through 
<edit-config> explicitly has no effect on server configuration, and would
never
result in an error.

----------------------------------------------------------------------------
--------------- 

would clarify it. But it should not appear as errata item IMO.

> creating containers that have no real meaning".   The opposite

I also don't like the idea of placing this kind of restrictions in the
client. 

Best
-Xiang

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Aug 2016 16:50:45 -0700

Hi,

I think we agree that YANG 1.1 says an NP container exists if its parent
exists.
I am not proposing to change that consensus, and perhaps nobody else is
either.

So now we have a definition of an NP container instance.
NETCONF is rather clear wrt/ how operations behave regarding data node
existence.

Using this rather clear definition of NETCONF edit operations and
NP container existence, it seems obvious that

  1) a "create" operation always fails on an NP container with a
data-exists error
  2) a "delete" operation never fails because of a data-missing error.
     Both "delete" and "remove" justs deletes all child nodes.  They have
no affect on empty
     NP containers

This would be consistent with RFC 6241 and how we already treat default
leafs.

Andy

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 19 Aug 2016 19:04:10 -0700

Moving the thread from netconf to netmod.

Will the authors pull 6020bis back into the WG to reach the rough consensus?

> On Aug 17, 2016, at 2:13 AM, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

Mahesh Jethanandani
[email-masked]