Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Ladislav Lhotka]

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
>> > On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
>> > > > Here is an attempt to rewrite things in a way according to how I
>> > > > understand things works. It should be possible to describe what we
>> > > > mean. If we can't do that, we have a bigger problem. (I have changed
>> > > > only the last two sentences.)
>> > > > 
>> > > > OLD
>> > > > 
>> > > >The leafref built-in type is restricted to the value space of some
>> > > >leaf or leaf-list node in the schema tree and optionally further
>> > > >restricted by corresponding instance nodes in the data tree.  The
>> > > >"path" substatement (Section 9.9.2) is used to identify the referred
>> > > >leaf or leaf-list node in the schema tree.  The value space of the
>> > > >referring node is the value space of the referred node.
>> > > > 
>> > > > NEW
>> > > > 
>> > > >The leafref built-in type is restricted to the value space of some
>> > > >leaf or leaf-list node in the schema tree and optionally further
>> > > >restricted by corresponding instance nodes in the data tree.  The
>> > > >"path" substatement (Section 9.9.2) is used to identify a leaf or
>> > > >leaf-list node in the data tree. The value space of the leafref
>> > > >node is determined by the value space of the schema tree node
>> > > 
>> > > The term "value space of a schema tree node" is not defined.
>> > 
>> > OK. So we say 'the value space of the type of the schema tree node'.
>> 
>> Yes, this is better. But what if the schema tree node is made invalid due to 
>> a
>> failed "when" expression? Does it still apply?
>
> Yes.  I'm sure the text around "when" can be improved, but the idea is
> that if the when expression is false, the schema node becomes
> "invalid"; but it still exists.
>
>> > > >definining the referenced data tree node.
>> > > 
>> > > With require-instance=false there needn't be any referenced data tree 
>> > > node.
>> > 
>> > So we add "(irrespective whether the node exists or not).
>> 
>> If the data tree node doesn't exist, we cannot refer to the schema tree node
>> that defines it.
>
> It's pretty clear what the intention is, right?  So what are the right
> words to explain it?
>
>
>> > > > This likely is not perfect yet but perhaps we manage to make it
>> > > > perfect. ;-) What is not yet clearly described I think is what
>> > > > 'further restricted by corresponding instance nodes in the data tree'
>> > > > means (and that I think depends on require-instance). Perhaps add
>> > > 
>> > > Right. In this case it is not "further restricted" but rather there is a
>> > > discrete set of possible values.
>> > 
>> > A discrete set of possible values is a restriction so I do not
>> > understand your comment. So here is the next iteration:
>> 
>> If required-instance is true, there is no need to care about all this tricky
>> stuff with schema tree nodes and their types. In other words:
>> 
>> 1. if required-instance = true, the permitted values are obtained from the 
>> data
>> tree.
>
> Not true in the candidate.  See also the mail thread you quoted.

This actually indicates that the text "optionally further restricted" is
fundamentally wrong because it seems to suggest that "require-instance
true" is just an additional restriction of leafref's type. But it is
apparently not the case:

- #2 is always used for determining the "inherited" type that has to be
  satisfied in all data trees

- #1 adds a semantic constraint that only has to be satisfied in a valid
  tree.

Lada

>
>
> /martin
>
>
>> 2. if required-instance = false, the corresponding schema node has to be
>> determined, and its type defines the permitted values of the leafref node.
>> 
>> It is an exclusive-or, #1 is not an "optional further restriction".
>> 
>> Lada
>> 
>> > 
>> > NEW:
>> > 
>> > The leafref built-in type is restricted to the value space of some
>> > leaf or leaf-list node in the schema tree and optionally further
>> > restricted by corresponding instance nodes in the data tree (see
>> > Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
>> > to identify a leaf or leaf-list node in the data tree. The value
>> > space of the leafref node is determined by the value space of the
>> > type of the schema tree node definining the referenced data tree
>> > node (irrespective whether the referenced data tree node exists or
>> > not).
>> > 
>> > /js
>> > 
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 

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

___
netmod mailing list
netmod@ietf.org

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Andy Bierman]

On Fri, Nov 23, 2018 at 1:00 PM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Fri, Nov 23, 2018 at 09:23:01AM -0800, Andy Bierman wrote:
> >
> > IMO the RFC has a lot of room for improvement in this area:
> >
> >  - the term "data node" is never defined but used 47 times
> >  - the term "data node identifier" is not defined or used
> >  - the term "schema node identifier" is defined and used 14 times
> >(defined in sec. 3 Terminology and again in sec. 6.5)
> >  - every statement that uses some sort of path identifier (e.g. 9.9.2)
> > needs to clearly specify
> >whether the syntax is based on schema-node identifier or data-node
> > identifier
> >
>
> We either fix one thing at a time or we give up and hope for a better
> future to arrive somehow.
>
>
This is one thing : make it clear where the syntax includes choice/case
identifiers
and where it does not.  The solutions I have seen so far for clarifying
9.9.2
do not do that.



> /js
>


Andy


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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Juergen Schoenwaelder]

On Fri, Nov 23, 2018 at 09:23:01AM -0800, Andy Bierman wrote:
> 
> IMO the RFC has a lot of room for improvement in this area:
> 
>  - the term "data node" is never defined but used 47 times
>  - the term "data node identifier" is not defined or used
>  - the term "schema node identifier" is defined and used 14 times
>(defined in sec. 3 Terminology and again in sec. 6.5)
>  - every statement that uses some sort of path identifier (e.g. 9.9.2)
> needs to clearly specify
>whether the syntax is based on schema-node identifier or data-node
> identifier
>

We either fix one thing at a time or we give up and hope for a better
future to arrive somehow.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Andy Bierman]

On Fri, Nov 23, 2018 at 5:37 AM Robert Wilton  wrote:

>
> On 23/11/2018 13:29, Ladislav Lhotka wrote:
> > On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
> >> On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
>  Here is an attempt to rewrite things in a way according to how I
>  understand things works. It should be possible to describe what we
>  mean. If we can't do that, we have a bigger problem. (I have changed
>  only the last two sentences.)
> 
>  OLD
> 
>  The leafref built-in type is restricted to the value space of some
>  leaf or leaf-list node in the schema tree and optionally further
>  restricted by corresponding instance nodes in the data tree.  The
>  "path" substatement (Section 9.9.2) is used to identify the
> referred
>  leaf or leaf-list node in the schema tree.  The value space of the
>  referring node is the value space of the referred node.
> 
>  NEW
> 
>  The leafref built-in type is restricted to the value space of some
>  leaf or leaf-list node in the schema tree and optionally further
>  restricted by corresponding instance nodes in the data tree.  The
>  "path" substatement (Section 9.9.2) is used to identify a leaf or
>  leaf-list node in the data tree. The value space of the leafref
>  node is determined by the value space of the schema tree node
> >>> The term "value space of a schema tree node" is not defined.
> >> OK. So we say 'the value space of the type of the schema tree node'.
> > Yes, this is better. But what if the schema tree node is made invalid
> due to a
> > failed "when" expression? Does it still apply?
>
> I might be being picky, but it isn't absolutely clear from the text
> which node "schema tree node" refers to.
>
> Hence I wonder whether it might be better to say "...identify the
> referenced leaf or leaflist ..." and "value space of the referenced
> schema tree node".
>
>

IMO the RFC has a lot of room for improvement in this area:

 - the term "data node" is never defined but used 47 times
 - the term "data node identifier" is not defined or used
 - the term "schema node identifier" is defined and used 14 times
   (defined in sec. 3 Terminology and again in sec. 6.5)
 - every statement that uses some sort of path identifier (e.g. 9.9.2)
needs to clearly specify
   whether the syntax is based on schema-node identifier or data-node
identifier



> Thanks,
> Rob
>
>

Andy



>
> >
> >>
>  definining the referenced data tree node.
> >>> With require-instance=false there needn't be any referenced data tree
> node.
> >> So we add "(irrespective whether the node exists or not).
> > If the data tree node doesn't exist, we cannot refer to the schema tree
> node
> > that defines it.
> >
>  This likely is not perfect yet but perhaps we manage to make it
>  perfect. ;-) What is not yet clearly described I think is what
>  'further restricted by corresponding instance nodes in the data tree'
>  means (and that I think depends on require-instance). Perhaps add
> >>> Right. In this case it is not "further restricted" but rather there is
> a
> >>> discrete set of possible values.
> >> A discrete set of possible values is a restriction so I do not
> >> understand your comment. So here is the next iteration:
> > If required-instance is true, there is no need to care about all this
> tricky
> > stuff with schema tree nodes and their types. In other words:
> >
> > 1. if required-instance = true, the permitted values are obtained from
> the data
> > tree.
> >
> > 2. if required-instance = false, the corresponding schema node has to be
> > determined, and its type defines the permitted values of the leafref
> node.
> >
> > It is an exclusive-or, #1 is not an "optional further restriction".
> >
> > Lada
> >
> >> NEW:
> >>
> >>  The leafref built-in type is restricted to the value space of some
> >>  leaf or leaf-list node in the schema tree and optionally further
> >>  restricted by corresponding instance nodes in the data tree (see
> >>  Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
> >>  to identify a leaf or leaf-list node in the data tree. The value
> >>  space of the leafref node is determined by the value space of the
> >>  type of the schema tree node definining the referenced data tree
> >>  node (irrespective whether the referenced data tree node exists or
> >>  not).
> >>
> >> /js
> >>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Juergen Schoenwaelder]

On Fri, Nov 23, 2018 at 02:29:18PM +0100, Ladislav Lhotka wrote:
> On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
> > On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
> > > > Here is an attempt to rewrite things in a way according to how I
> > > > understand things works. It should be possible to describe what we
> > > > mean. If we can't do that, we have a bigger problem. (I have changed
> > > > only the last two sentences.)
> > > > 
> > > > OLD
> > > > 
> > > >The leafref built-in type is restricted to the value space of some
> > > >leaf or leaf-list node in the schema tree and optionally further
> > > >restricted by corresponding instance nodes in the data tree.  The
> > > >"path" substatement (Section 9.9.2) is used to identify the referred
> > > >leaf or leaf-list node in the schema tree.  The value space of the
> > > >referring node is the value space of the referred node.
> > > > 
> > > > NEW
> > > > 
> > > >The leafref built-in type is restricted to the value space of some
> > > >leaf or leaf-list node in the schema tree and optionally further
> > > >restricted by corresponding instance nodes in the data tree.  The
> > > >"path" substatement (Section 9.9.2) is used to identify a leaf or
> > > >leaf-list node in the data tree. The value space of the leafref
> > > >node is determined by the value space of the schema tree node
> > > 
> > > The term "value space of a schema tree node" is not defined.
> > 
> > OK. So we say 'the value space of the type of the schema tree node'.
> 
> Yes, this is better. But what if the schema tree node is made invalid due to a
> failed "when" expression? Does it still apply?

Why do you think it would not?

> > > >definining the referenced data tree node.
> > > 
> > > With require-instance=false there needn't be any referenced data tree 
> > > node.
> > 
> > So we add "(irrespective whether the node exists or not).
> 
> If the data tree node doesn't exist, we cannot refer to the schema tree node
> that defines it.

What is the problem? There is a path on the instance data tree and it
seems decidable what the matching path in the schema tree is. Can you
construct an example where this is not decidable?

> If required-instance is true, there is no need to care about all this tricky
> stuff with schema tree nodes and their types. In other words:
> 
> 1. if required-instance = true, the permitted values are obtained from the 
> data
> tree.
> 
> 2. if required-instance = false, the corresponding schema node has to be
> determined, and its type defines the permitted values of the leafref node.
> 
> It is an exclusive-or, #1 is not an "optional further restriction".

Since the data node values must comply to the data type of the schema
node, it is a further restriction. Anyway, you are welcome to propose
better wording or convince us that this can't be implemented. If it is
implementable, we should be able to describe how things work.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Ladislav Lhotka]

On Fri, 2018-11-23 at 15:09 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
> > > On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
> > > > > Here is an attempt to rewrite things in a way according to how I
> > > > > understand things works. It should be possible to describe what we
> > > > > mean. If we can't do that, we have a bigger problem. (I have changed
> > > > > only the last two sentences.)
> > > > > 
> > > > > OLD
> > > > > 
> > > > >The leafref built-in type is restricted to the value space of some
> > > > >leaf or leaf-list node in the schema tree and optionally further
> > > > >restricted by corresponding instance nodes in the data tree.  The
> > > > >"path" substatement (Section 9.9.2) is used to identify the
> referred
> > > > >leaf or leaf-list node in the schema tree.  The value space of the
> > > > >referring node is the value space of the referred node.
> > > > > 
> > > > > NEW
> > > > > 
> > > > >The leafref built-in type is restricted to the value space of some
> > > > >leaf or leaf-list node in the schema tree and optionally further
> > > > >restricted by corresponding instance nodes in the data tree.  The
> > > > >"path" substatement (Section 9.9.2) is used to identify a leaf or
> > > > >leaf-list node in the data tree. The value space of the leafref
> > > > >node is determined by the value space of the schema tree node
> > > > 
> > > > The term "value space of a schema tree node" is not defined.
> > > 
> > > OK. So we say 'the value space of the type of the schema tree node'.
> > 
> > Yes, this is better. But what if the schema tree node is made invalid due to
> a
> > failed "when" expression? Does it still apply?
> 
> Yes.  I'm sure the text around "when" can be improved, but the idea is
> that if the when expression is false, the schema node becomes
> "invalid"; but it still exists.

But then no referred-to leaf instance can exist, so does the leafref make sense
at all?

And what about if-feature: can I have an instance of a leafref pointing to a
leaf that depends on a feature, and the feature is not active?

> 
> > > > >definining the referenced data tree node.
> > > > 
> > > > With require-instance=false there needn't be any referenced data tree
> node.
> > > 
> > > So we add "(irrespective whether the node exists or not).
> > 
> > If the data tree node doesn't exist, we cannot refer to the schema tree node
> > that defines it.
> 
> It's pretty clear what the intention is, right?  So what are the right
> words to explain it?

The right words have to avoid mentioning any data tree nodes because there may
be none. It is necessary to explain how the schema tree is traversed based on
the path expression. This basically means:

- ".." = ascend to the closest ancestor data node
- skip all predicates
- if there is an intervening choice in the schema, determine the right case and
descend to it

> 
> 
> > > > > This likely is not perfect yet but perhaps we manage to make it
> > > > > perfect. ;-) What is not yet clearly described I think is what
> > > > > 'further restricted by corresponding instance nodes in the data tree'
> > > > > means (and that I think depends on require-instance). Perhaps add
> > > > 
> > > > Right. In this case it is not "further restricted" but rather there is a
> > > > discrete set of possible values.
> > > 
> > > A discrete set of possible values is a restriction so I do not
> > > understand your comment. So here is the next iteration:
> > 
> > If required-instance is true, there is no need to care about all this tricky
> > stuff with schema tree nodes and their types. In other words:
> > 
> > 1. if required-instance = true, the permitted values are obtained from the
> data
> > tree.
> 
> Not true in the candidate.  See also the mail thread you quoted.

Hmm, so you are saying that in candidate require-instance is ignored but the
leafref's value must still be inside the value space defined by #2? This is IMO
not clear at all.

Lada

> 
> 
> /martin
> 
> 
> > 2. if required-instance = false, the corresponding schema node has to be
> > determined, and its type defines the permitted values of the leafref node.
> > 
> > It is an exclusive-or, #1 is not an "optional further restriction".
> > 
> > Lada
> > 
> > > 
> > > NEW:
> > > 
> > > The leafref built-in type is restricted to the value space of some
> > > leaf or leaf-list node in the schema tree and optionally further
> > > restricted by corresponding instance nodes in the data tree (see
> > > Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
> > > to identify a leaf or leaf-list node in the data tree. The value
> > > space of the leafref node is determined by the value space of the
> > > type of the schema tree node definining the referenced data tree
> > > node (irrespective whether the referenced data tree node exists or

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
> > On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
> > > > Here is an attempt to rewrite things in a way according to how I
> > > > understand things works. It should be possible to describe what we
> > > > mean. If we can't do that, we have a bigger problem. (I have changed
> > > > only the last two sentences.)
> > > > 
> > > > OLD
> > > > 
> > > >The leafref built-in type is restricted to the value space of some
> > > >leaf or leaf-list node in the schema tree and optionally further
> > > >restricted by corresponding instance nodes in the data tree.  The
> > > >"path" substatement (Section 9.9.2) is used to identify the referred
> > > >leaf or leaf-list node in the schema tree.  The value space of the
> > > >referring node is the value space of the referred node.
> > > > 
> > > > NEW
> > > > 
> > > >The leafref built-in type is restricted to the value space of some
> > > >leaf or leaf-list node in the schema tree and optionally further
> > > >restricted by corresponding instance nodes in the data tree.  The
> > > >"path" substatement (Section 9.9.2) is used to identify a leaf or
> > > >leaf-list node in the data tree. The value space of the leafref
> > > >node is determined by the value space of the schema tree node
> > > 
> > > The term "value space of a schema tree node" is not defined.
> > 
> > OK. So we say 'the value space of the type of the schema tree node'.
> 
> Yes, this is better. But what if the schema tree node is made invalid due to a
> failed "when" expression? Does it still apply?

Yes.  I'm sure the text around "when" can be improved, but the idea is
that if the when expression is false, the schema node becomes
"invalid"; but it still exists.

> > > >definining the referenced data tree node.
> > > 
> > > With require-instance=false there needn't be any referenced data tree 
> > > node.
> > 
> > So we add "(irrespective whether the node exists or not).
> 
> If the data tree node doesn't exist, we cannot refer to the schema tree node
> that defines it.

It's pretty clear what the intention is, right?  So what are the right
words to explain it?


> > > > This likely is not perfect yet but perhaps we manage to make it
> > > > perfect. ;-) What is not yet clearly described I think is what
> > > > 'further restricted by corresponding instance nodes in the data tree'
> > > > means (and that I think depends on require-instance). Perhaps add
> > > 
> > > Right. In this case it is not "further restricted" but rather there is a
> > > discrete set of possible values.
> > 
> > A discrete set of possible values is a restriction so I do not
> > understand your comment. So here is the next iteration:
> 
> If required-instance is true, there is no need to care about all this tricky
> stuff with schema tree nodes and their types. In other words:
> 
> 1. if required-instance = true, the permitted values are obtained from the 
> data
> tree.

Not true in the candidate.  See also the mail thread you quoted.


/martin


> 2. if required-instance = false, the corresponding schema node has to be
> determined, and its type defines the permitted values of the leafref node.
> 
> It is an exclusive-or, #1 is not an "optional further restriction".
> 
> Lada
> 
> > 
> > NEW:
> > 
> > The leafref built-in type is restricted to the value space of some
> > leaf or leaf-list node in the schema tree and optionally further
> > restricted by corresponding instance nodes in the data tree (see
> > Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
> > to identify a leaf or leaf-list node in the data tree. The value
> > space of the leafref node is determined by the value space of the
> > type of the schema tree node definining the referenced data tree
> > node (irrespective whether the referenced data tree node exists or
> > not).
> > 
> > /js
> > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Robert Wilton]

On 23/11/2018 13:29, Ladislav Lhotka wrote:

On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:

On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:

Here is an attempt to rewrite things in a way according to how I
understand things works. It should be possible to describe what we
mean. If we can't do that, we have a bigger problem. (I have changed
only the last two sentences.)

OLD

The leafref built-in type is restricted to the value space of some
leaf or leaf-list node in the schema tree and optionally further
restricted by corresponding instance nodes in the data tree.  The
"path" substatement (Section 9.9.2) is used to identify the referred
leaf or leaf-list node in the schema tree.  The value space of the
referring node is the value space of the referred node.

NEW

The leafref built-in type is restricted to the value space of some
leaf or leaf-list node in the schema tree and optionally further
restricted by corresponding instance nodes in the data tree.  The
"path" substatement (Section 9.9.2) is used to identify a leaf or
leaf-list node in the data tree. The value space of the leafref
node is determined by the value space of the schema tree node

The term "value space of a schema tree node" is not defined.

OK. So we say 'the value space of the type of the schema tree node'.

Yes, this is better. But what if the schema tree node is made invalid due to a
failed "when" expression? Does it still apply?


I might be being picky, but it isn't absolutely clear from the text 
which node "schema tree node" refers to.


Hence I wonder whether it might be better to say "...identify the 
referenced leaf or leaflist ..." and "value space of the referenced 
schema tree node".


Thanks,
Rob




  

definining the referenced data tree node.

With require-instance=false there needn't be any referenced data tree node.

So we add "(irrespective whether the node exists or not).

If the data tree node doesn't exist, we cannot refer to the schema tree node
that defines it.


This likely is not perfect yet but perhaps we manage to make it
perfect. ;-) What is not yet clearly described I think is what
'further restricted by corresponding instance nodes in the data tree'
means (and that I think depends on require-instance). Perhaps add

Right. In this case it is not "further restricted" but rather there is a
discrete set of possible values.

A discrete set of possible values is a restriction so I do not
understand your comment. So here is the next iteration:

If required-instance is true, there is no need to care about all this tricky
stuff with schema tree nodes and their types. In other words:

1. if required-instance = true, the permitted values are obtained from the data
tree.

2. if required-instance = false, the corresponding schema node has to be
determined, and its type defines the permitted values of the leafref node.

It is an exclusive-or, #1 is not an "optional further restriction".

Lada


NEW:

 The leafref built-in type is restricted to the value space of some
 leaf or leaf-list node in the schema tree and optionally further
 restricted by corresponding instance nodes in the data tree (see
 Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
 to identify a leaf or leaf-list node in the data tree. The value
 space of the leafref node is determined by the value space of the
 type of the schema tree node definining the referenced data tree
 node (irrespective whether the referenced data tree node exists or
 not).

/js



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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Ladislav Lhotka]

On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
> On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
> > > Here is an attempt to rewrite things in a way according to how I
> > > understand things works. It should be possible to describe what we
> > > mean. If we can't do that, we have a bigger problem. (I have changed
> > > only the last two sentences.)
> > > 
> > > OLD
> > > 
> > >The leafref built-in type is restricted to the value space of some
> > >leaf or leaf-list node in the schema tree and optionally further
> > >restricted by corresponding instance nodes in the data tree.  The
> > >"path" substatement (Section 9.9.2) is used to identify the referred
> > >leaf or leaf-list node in the schema tree.  The value space of the
> > >referring node is the value space of the referred node.
> > > 
> > > NEW
> > > 
> > >The leafref built-in type is restricted to the value space of some
> > >leaf or leaf-list node in the schema tree and optionally further
> > >restricted by corresponding instance nodes in the data tree.  The
> > >"path" substatement (Section 9.9.2) is used to identify a leaf or
> > >leaf-list node in the data tree. The value space of the leafref
> > >node is determined by the value space of the schema tree node
> > 
> > The term "value space of a schema tree node" is not defined.
> 
> OK. So we say 'the value space of the type of the schema tree node'.

Yes, this is better. But what if the schema tree node is made invalid due to a
failed "when" expression? Does it still apply?

>  
> > >definining the referenced data tree node.
> > 
> > With require-instance=false there needn't be any referenced data tree node.
> 
> So we add "(irrespective whether the node exists or not).

If the data tree node doesn't exist, we cannot refer to the schema tree node
that defines it.

> 
> > > This likely is not perfect yet but perhaps we manage to make it
> > > perfect. ;-) What is not yet clearly described I think is what
> > > 'further restricted by corresponding instance nodes in the data tree'
> > > means (and that I think depends on require-instance). Perhaps add
> > 
> > Right. In this case it is not "further restricted" but rather there is a
> > discrete set of possible values.
> 
> A discrete set of possible values is a restriction so I do not
> understand your comment. So here is the next iteration:

If required-instance is true, there is no need to care about all this tricky
stuff with schema tree nodes and their types. In other words:

1. if required-instance = true, the permitted values are obtained from the data
tree.

2. if required-instance = false, the corresponding schema node has to be
determined, and its type defines the permitted values of the leafref node.

It is an exclusive-or, #1 is not an "optional further restriction".

Lada

> 
> NEW:
> 
> The leafref built-in type is restricted to the value space of some
> leaf or leaf-list node in the schema tree and optionally further
> restricted by corresponding instance nodes in the data tree (see
> Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
> to identify a leaf or leaf-list node in the data tree. The value
> space of the leafref node is determined by the value space of the
> type of the schema tree node definining the referenced data tree
> node (irrespective whether the referenced data tree node exists or
> not).
> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Juergen Schoenwaelder]

On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
> > 
> > Here is an attempt to rewrite things in a way according to how I
> > understand things works. It should be possible to describe what we
> > mean. If we can't do that, we have a bigger problem. (I have changed
> > only the last two sentences.)
> > 
> > OLD
> > 
> >The leafref built-in type is restricted to the value space of some
> >leaf or leaf-list node in the schema tree and optionally further
> >restricted by corresponding instance nodes in the data tree.  The
> >"path" substatement (Section 9.9.2) is used to identify the referred
> >leaf or leaf-list node in the schema tree.  The value space of the
> >referring node is the value space of the referred node.
> > 
> > NEW
> > 
> >The leafref built-in type is restricted to the value space of some
> >leaf or leaf-list node in the schema tree and optionally further
> >restricted by corresponding instance nodes in the data tree.  The
> >"path" substatement (Section 9.9.2) is used to identify a leaf or
> >leaf-list node in the data tree. The value space of the leafref
> >node is determined by the value space of the schema tree node
> 
> The term "value space of a schema tree node" is not defined.

OK. So we say 'the value space of the type of the schema tree node'.
 
> >definining the referenced data tree node.
> 
> With require-instance=false there needn't be any referenced data tree node.

So we add "(irrespective whether the node exists or not).

> > This likely is not perfect yet but perhaps we manage to make it
> > perfect. ;-) What is not yet clearly described I think is what
> > 'further restricted by corresponding instance nodes in the data tree'
> > means (and that I think depends on require-instance). Perhaps add
> 
> Right. In this case it is not "further restricted" but rather there is a
> discrete set of possible values.

A discrete set of possible values is a restriction so I do not
understand your comment. So here is the next iteration:

NEW:

The leafref built-in type is restricted to the value space of some
leaf or leaf-list node in the schema tree and optionally further
restricted by corresponding instance nodes in the data tree (see
Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
to identify a leaf or leaf-list node in the data tree. The value
space of the leafref node is determined by the value space of the
type of the schema tree node definining the referenced data tree
node (irrespective whether the referenced data tree node exists or
not).

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Ladislav Lhotka]

On Fri, 2018-11-23 at 12:33 +0100, Juergen Schoenwaelder wrote:
> On Fri, Nov 23, 2018 at 11:05:48AM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Fri, Nov 23, 2018 at 10:22:11AM +0100, Ladislav Lhotka wrote:
> > > > Juergen Schoenwaelder  writes:
> > > > 
> > > > > On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
> > > > > > Andy Bierman  wrote:
> > > > > > > 9.9 ;.  The
> > > > > > > leafref
> > > > > > > Built-In Type
> > > > > > > 
> > > > > > >The leafref built-in type is restricted to the value space of
> > > > > > > some
> > > > > > >leaf or leaf-list node in the schema tree and optionally
> > > > > > > further
> > > > > > >restricted by corresponding instance nodes in the data
> > > > > > > tree.  The
> > > > > > >"path" substatement (Section 9.9.2
> > > > > > > ;) is used to
> > > > > > > identify the referred
> > > > > > >leaf or leaf-list node in the schema tree.  The value space of
> > > > > > > the
> > > > > > >referring node is the value space of the referred node.
> > > > > > 
> > > > > > Yes, it should be "data tree" in both occurrences.
> > > > > 
> > > > > Time for an errata?
> > > > 
> > > > Here is the old discussion thread:
> > > > 
> > > > https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html
> > > > 
> > > > Everything relevant had been extensively discussed in it, and I am
> > > > sceptical that we can come up with anything significantly better - it
> > > > will only be more (or different) hand-waving. The problem is inherent in
> > > > the leafref design introduced in YANG 1.1. It won't go away no matter
> > > > how much we paper over it.
> > > > 
> > > 
> > > So you think the use of 'schema tree' in the text quoted above (is
> > > used to identify the referred leaf or leaf-list node in the schema
> > > tree) is correct??
> > > 
> > > I do not want to discuss whether you like the design of leafrefs or
> > > not here - at this time we should focus on whether the text is correct
> > > or not given the design we have. So again, you think that 'schema
> > > tree' is correct in the statement?
> > 
> > After reading the quoted thread and thinking some more, I think the
> > text in 9.9 is in fact correct.  As Lada wrote in that thread:
> >  
> >2. It [path] also implicitly refers to a leaf node in the schema
> >   [...]
> > 
> > The problem is that this "implicit reference" isn't defined.  9.9
> > talks about reference to a schema node, and 9.9.2 talks about the data
> > tree, but there is no text that ties these together.
> 
> Here is an attempt to rewrite things in a way according to how I
> understand things works. It should be possible to describe what we
> mean. If we can't do that, we have a bigger problem. (I have changed
> only the last two sentences.)
> 
> OLD
> 
>The leafref built-in type is restricted to the value space of some
>leaf or leaf-list node in the schema tree and optionally further
>restricted by corresponding instance nodes in the data tree.  The
>"path" substatement (Section 9.9.2) is used to identify the referred
>leaf or leaf-list node in the schema tree.  The value space of the
>referring node is the value space of the referred node.
> 
> NEW
> 
>The leafref built-in type is restricted to the value space of some
>leaf or leaf-list node in the schema tree and optionally further
>restricted by corresponding instance nodes in the data tree.  The
>"path" substatement (Section 9.9.2) is used to identify a leaf or
>leaf-list node in the data tree. The value space of the leafref
>node is determined by the value space of the schema tree node

The term "value space of a schema tree node" is not defined.


>definining the referenced data tree node.

With require-instance=false there needn't be any referenced data tree node.

> 
> This likely is not perfect yet but perhaps we manage to make it
> perfect. ;-) What is not yet clearly described I think is what
> 'further restricted by corresponding instance nodes in the data tree'
> means (and that I think depends on require-instance). Perhaps add

Right. In this case it is not "further restricted" but rather there is a
discrete set of possible values.

Lada

> '(see Section 9.9.3)' to the end of the first sentence to handle this.
> 
> /js
>
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Juergen Schoenwaelder]

On Fri, Nov 23, 2018 at 11:05:48AM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Fri, Nov 23, 2018 at 10:22:11AM +0100, Ladislav Lhotka wrote:
> > > Juergen Schoenwaelder  writes:
> > > 
> > > > On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
> > > >> Andy Bierman  wrote:
> > > >> > 
> > > >> > 9.9 .  The leafref
> > > >> > Built-In Type
> > > >> > 
> > > >> >The leafref built-in type is restricted to the value space of some
> > > >> >leaf or leaf-list node in the schema tree and optionally further
> > > >> >restricted by corresponding instance nodes in the data tree.  The
> > > >> >"path" substatement (Section 9.9.2
> > > >> > ) is used to
> > > >> > identify the referred
> > > >> >leaf or leaf-list node in the schema tree.  The value space of the
> > > >> >referring node is the value space of the referred node.
> > > >> 
> > > >> Yes, it should be "data tree" in both occurrences.
> > > >
> > > > Time for an errata?
> > > 
> > > Here is the old discussion thread:
> > > 
> > > https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html
> > > 
> > > Everything relevant had been extensively discussed in it, and I am
> > > sceptical that we can come up with anything significantly better - it
> > > will only be more (or different) hand-waving. The problem is inherent in
> > > the leafref design introduced in YANG 1.1. It won't go away no matter
> > > how much we paper over it.
> > >
> > 
> > So you think the use of 'schema tree' in the text quoted above (is
> > used to identify the referred leaf or leaf-list node in the schema
> > tree) is correct??
> > 
> > I do not want to discuss whether you like the design of leafrefs or
> > not here - at this time we should focus on whether the text is correct
> > or not given the design we have. So again, you think that 'schema
> > tree' is correct in the statement?
> 
> After reading the quoted thread and thinking some more, I think the
> text in 9.9 is in fact correct.  As Lada wrote in that thread:
>  
>2. It [path] also implicitly refers to a leaf node in the schema
>   [...]
> 
> The problem is that this "implicit reference" isn't defined.  9.9
> talks about reference to a schema node, and 9.9.2 talks about the data
> tree, but there is no text that ties these together.

Here is an attempt to rewrite things in a way according to how I
understand things works. It should be possible to describe what we
mean. If we can't do that, we have a bigger problem. (I have changed
only the last two sentences.)

OLD

   The leafref built-in type is restricted to the value space of some
   leaf or leaf-list node in the schema tree and optionally further
   restricted by corresponding instance nodes in the data tree.  The
   "path" substatement (Section 9.9.2) is used to identify the referred
   leaf or leaf-list node in the schema tree.  The value space of the
   referring node is the value space of the referred node.

NEW

   The leafref built-in type is restricted to the value space of some
   leaf or leaf-list node in the schema tree and optionally further
   restricted by corresponding instance nodes in the data tree.  The
   "path" substatement (Section 9.9.2) is used to identify a leaf or
   leaf-list node in the data tree. The value space of the leafref
   node is determined by the value space of the schema tree node
   definining the referenced data tree node.

This likely is not perfect yet but perhaps we manage to make it
perfect. ;-) What is not yet clearly described I think is what
'further restricted by corresponding instance nodes in the data tree'
means (and that I think depends on require-instance). Perhaps add
'(see Section 9.9.3)' to the end of the first sentence to handle this.

/js
   
-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Ladislav Lhotka]

On Fri, 2018-11-23 at 11:05 +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Fri, Nov 23, 2018 at 10:22:11AM +0100, Ladislav Lhotka wrote:
> > > Juergen Schoenwaelder  writes:
> > > 
> > > > On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
> > > > > Andy Bierman  wrote:
> > > > > > 9.9 ;.  The leafref
> > > > > > Built-In Type
> > > > > > 
> > > > > >The leafref built-in type is restricted to the value space of
> > > > > > some
> > > > > >leaf or leaf-list node in the schema tree and optionally further
> > > > > >restricted by corresponding instance nodes in the data tree.  The
> > > > > >"path" substatement (Section 9.9.2
> > > > > > ;) is used to
> > > > > > identify the referred
> > > > > >leaf or leaf-list node in the schema tree.  The value space of
> > > > > > the
> > > > > >referring node is the value space of the referred node.
> > > > > 
> > > > > Yes, it should be "data tree" in both occurrences.
> > > > 
> > > > Time for an errata?
> > > 
> > > Here is the old discussion thread:
> > > 
> > > https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html
> > > 
> > > Everything relevant had been extensively discussed in it, and I am
> > > sceptical that we can come up with anything significantly better - it
> > > will only be more (or different) hand-waving. The problem is inherent in
> > > the leafref design introduced in YANG 1.1. It won't go away no matter
> > > how much we paper over it.
> > > 
> > 
> > So you think the use of 'schema tree' in the text quoted above (is
> > used to identify the referred leaf or leaf-list node in the schema
> > tree) is correct??
> > 
> > I do not want to discuss whether you like the design of leafrefs or
> > not here - at this time we should focus on whether the text is correct
> > or not given the design we have. So again, you think that 'schema
> > tree' is correct in the statement?
> 
> After reading the quoted thread and thinking some more, I think the
> text in 9.9 is in fact correct.  As Lada wrote in that thread:
>  
>2. It [path] also implicitly refers to a leaf node in the schema
>   [...]
> 
> The problem is that this "implicit reference" isn't defined.  9.9
> talks about reference to a schema node, and 9.9.2 talks about the data
> tree, but there is no text that ties these together.

Agreed. Lada

> 
> 
> /martin
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Fri, Nov 23, 2018 at 10:22:11AM +0100, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder  writes:
> > 
> > > On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
> > >> Andy Bierman  wrote:
> > >> > 
> > >> > 9.9 .  The leafref
> > >> > Built-In Type
> > >> > 
> > >> >The leafref built-in type is restricted to the value space of some
> > >> >leaf or leaf-list node in the schema tree and optionally further
> > >> >restricted by corresponding instance nodes in the data tree.  The
> > >> >"path" substatement (Section 9.9.2
> > >> > ) is used to
> > >> > identify the referred
> > >> >leaf or leaf-list node in the schema tree.  The value space of the
> > >> >referring node is the value space of the referred node.
> > >> 
> > >> Yes, it should be "data tree" in both occurrences.
> > >
> > > Time for an errata?
> > 
> > Here is the old discussion thread:
> > 
> > https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html
> > 
> > Everything relevant had been extensively discussed in it, and I am
> > sceptical that we can come up with anything significantly better - it
> > will only be more (or different) hand-waving. The problem is inherent in
> > the leafref design introduced in YANG 1.1. It won't go away no matter
> > how much we paper over it.
> >
> 
> So you think the use of 'schema tree' in the text quoted above (is
> used to identify the referred leaf or leaf-list node in the schema
> tree) is correct??
> 
> I do not want to discuss whether you like the design of leafrefs or
> not here - at this time we should focus on whether the text is correct
> or not given the design we have. So again, you think that 'schema
> tree' is correct in the statement?

After reading the quoted thread and thinking some more, I think the
text in 9.9 is in fact correct.  As Lada wrote in that thread:
 
   2. It [path] also implicitly refers to a leaf node in the schema
  [...]

The problem is that this "implicit reference" isn't defined.  9.9
talks about reference to a schema node, and 9.9.2 talks about the data
tree, but there is no text that ties these together.


/martin

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Ladislav Lhotka]

On Fri, 2018-11-23 at 10:38 +0100, Juergen Schoenwaelder wrote:
> On Fri, Nov 23, 2018 at 10:22:11AM +0100, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder  writes:
> > 
> > > On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
> > > > Andy Bierman  wrote:
> > > > > 9.9 ;.  The leafref
> > > > > Built-In Type
> > > > > 
> > > > >The leafref built-in type is restricted to the value space of some
> > > > >leaf or leaf-list node in the schema tree and optionally further
> > > > >restricted by corresponding instance nodes in the data tree.  The
> > > > >"path" substatement (Section 9.9.2
> > > > > ;) is used to
> > > > > identify the referred
> > > > >leaf or leaf-list node in the schema tree.  The value space of the
> > > > >referring node is the value space of the referred node.
> > > > 
> > > > Yes, it should be "data tree" in both occurrences.
> > > 
> > > Time for an errata?
> > 
> > Here is the old discussion thread:
> > 
> > https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html
> > 
> > Everything relevant had been extensively discussed in it, and I am
> > sceptical that we can come up with anything significantly better - it
> > will only be more (or different) hand-waving. The problem is inherent in
> > the leafref design introduced in YANG 1.1. It won't go away no matter
> > how much we paper over it.
> > 
> 
> So you think the use of 'schema tree' in the text quoted above (is
> used to identify the referred leaf or leaf-list node in the schema
> tree) is correct??

It is certainly more correct than "data tree". The assumption is that the "path"
statement (that by definition selects some instance nodes in the data tree) also
implicitly points to a leaf or leaf-list node iin the schema tree.

> 
> I do not want to discuss whether you like the design of leafrefs or
> not here - at this time we should focus on whether the text is correct
> or not given the design we have. So again, you think that 'schema
> tree' is correct in the statement?

There are two problems with it:

1. There may be no such schema node, because it can be possibly invalidated by a
"when" expression.

2. The term "value space" is not defined.

Lada

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

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Juergen Schoenwaelder]

On Fri, Nov 23, 2018 at 10:22:11AM +0100, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
> >> Andy Bierman  wrote:
> >> > 
> >> > 9.9 .  The leafref
> >> > Built-In Type
> >> > 
> >> >The leafref built-in type is restricted to the value space of some
> >> >leaf or leaf-list node in the schema tree and optionally further
> >> >restricted by corresponding instance nodes in the data tree.  The
> >> >"path" substatement (Section 9.9.2
> >> > ) is used to
> >> > identify the referred
> >> >leaf or leaf-list node in the schema tree.  The value space of the
> >> >referring node is the value space of the referred node.
> >> 
> >> Yes, it should be "data tree" in both occurrences.
> >
> > Time for an errata?
> 
> Here is the old discussion thread:
> 
> https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html
> 
> Everything relevant had been extensively discussed in it, and I am
> sceptical that we can come up with anything significantly better - it
> will only be more (or different) hand-waving. The problem is inherent in
> the leafref design introduced in YANG 1.1. It won't go away no matter
> how much we paper over it.
>

So you think the use of 'schema tree' in the text quoted above (is
used to identify the referred leaf or leaf-list node in the schema
tree) is correct??

I do not want to discuss whether you like the design of leafrefs or
not here - at this time we should focus on whether the text is correct
or not given the design we have. So again, you think that 'schema
tree' is correct in the statement?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
>> Andy Bierman  wrote:
>> > 
>> > 9.9 .  The leafref
>> > Built-In Type
>> > 
>> >The leafref built-in type is restricted to the value space of some
>> >leaf or leaf-list node in the schema tree and optionally further
>> >restricted by corresponding instance nodes in the data tree.  The
>> >"path" substatement (Section 9.9.2
>> > ) is used to
>> > identify the referred
>> >leaf or leaf-list node in the schema tree.  The value space of the
>> >referring node is the value space of the referred node.
>> 
>> Yes, it should be "data tree" in both occurrences.
>
> Time for an errata?

Here is the old discussion thread:

https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html

Everything relevant had been extensively discussed in it, and I am
sceptical that we can come up with anything significantly better - it
will only be more (or different) hand-waving. The problem is inherent in
the leafref design introduced in YANG 1.1. It won't go away no matter
how much we paper over it.

Lada

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

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

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Juergen Schoenwaelder]

On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
> Andy Bierman  wrote:
> > 
> > 9.9 .  The leafref
> > Built-In Type
> > 
> >The leafref built-in type is restricted to the value space of some
> >leaf or leaf-list node in the schema tree and optionally further
> >restricted by corresponding instance nodes in the data tree.  The
> >"path" substatement (Section 9.9.2
> > ) is used to
> > identify the referred
> >leaf or leaf-list node in the schema tree.  The value space of the
> >referring node is the value space of the referred node.
> 
> Yes, it should be "data tree" in both occurrences.

Time for an errata?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Andy Bierman]

On Thu, Nov 22, 2018 at 7:28 AM Ladislav Lhotka  wrote:

> On Thu, 2018-11-22 at 16:14 +0100, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
> > > > Andy Bierman  wrote:
> > > > > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund 
> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Ladislav Lhotka  wrote:
> > > > > > > Andy Bierman  writes:
> > > > > > >
> > > > > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia -
> CA/Ottawa)
> > <
> > > > > > > > jason.ste...@nokia.com> wrote:
> > > > > > > >
> > > > > > > >> Hi all,
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> If we have a YANG model with a leaf:
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> MODEL VERSION 1:
> > > > > > > >>
> > > > > > > >> container my-model {
> > > > > > > >>
> > > > > > > >> leaf a { type string; }
> > > > > > > >>
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> And then later we produce another version of the model
> where that
> > > > > > leaf is
> > > > > > > >> placed into a choice construct:
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> MODEL VERSION 2:
> > > > > > > >>
> > > > > > > >> container my-model {
> > > > > > > >>
> > > > > > > >> choice some-choice {
> > > > > > > >>
> > > > > > > >> case x {
> > > > > > > >>
> > > > > > > >> leaf a { type string; }
> > > > > > > >>
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Is that considered a non-backwards-compatible change?
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > > yes -- even though the data node /my-model/x did not change,
> > > > > > > > the schema node /my-model/a changed to
> /my-model/some-choice/x/a.
> > > > > > > > Any leafref path pointing at this leaf will break.
> > > > > > >
> > > > > > > This is not correct. A leafref path is a special XPath, and as
> such
> > > > > > > includes only data nodes, i.e. NOT choice and case nodes.
> > > > > > >
> > > > > > > What does change are schema node identifier. This could be
> > significant
> > > > > > > in an augment statement, but not ini this example because a
> leaf
> > cannot
> > > > > > > be augmented anyway.
> > > > > > >
> > > > > > > I don't see anything else that could break, so Jason's change
> seems
> > > > > > > backward compatible to me.
> > > > > >
> > > > > > Since it does change the schema tree, this is not legal
> according to
> > > > > > 7950.  So in that sense it is not backwards compatible.  The
> rules in
> > > > > > 7950 protect both clients and other modules that import the
> module.
> > > > > >
> > > > > >
> > > > > This text is confusing wrt/ schema tree vs data tree:
> > > > >
> > > > >
> > > > > 9.9 ;;.  The
> leafref
> > > > > Built-In Type
> > > > >
> > > > >The leafref built-in type is restricted to the value space of
> some
> > > > >leaf or leaf-list node in the schema tree and optionally further
> > > > >restricted by corresponding instance nodes in the data tree.
> The
> > > > >"path" substatement (Section 9.9.2
> > > > > ;;) is used to
> > > > > identify the referred
> > > > >leaf or leaf-list node in the schema tree.  The value space of
> the
> > > > >referring node is the value space of the referred node.
> > > >
> > > > Yes, it should be "data tree" in both occurrences.
> > >
> > > I tend to disagree. The values of a leafref are first restricted
> according
> > to
> > > the *schema*, i.e. even before any leaf instance exists in the data
> tree
> > that
> > > the leafref can point to. Consider this example:
> > >
> > > list map {
> > >   key name;
> > >   leaf name {
> > > type string;
> > >   }
> > >   leaf value {
> > > type uint8;
> > >   }
> > > }
> > > leaf link {
> > >   type leafref {
> > > path "../map[name='quux']/value";
> > > default "foo";
> > >   }
> > > }
> > >
> > > We had a long discussion about this, maybe I could find it, and the
> > conclusion
> > > was that a YANG parser should flag the default "foo" value as
> incorrect even
> > > before any instance data are in sight.
> >
> > Yes, this is correct.  The quoted text needs to be rewritten to make
> > this more clear.  Altough the path refers to a (potential) node in the
> > data tree, that node obviously has a node in the schema tree, and its
> > value space restricts the value space of the leafref node.
> >
> > > I wasn't exactly happy with this conclusion because it assumes that we
> can
> > use
> > > the XPath from the argument of "path" to locate the *schema node* and
> check
> > its
> > > type. Although it looks appealing (everybody sees what the type of
> "value"
> > is,
> > > right?), I think this is just another 

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Per Hedeland]

On 2018-11-22 16:37, Ladislav Lhotka wrote:
> On Thu, 2018-11-22 at 15:31 +, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>> From what I can understand below, none of this debate affects the conclusion
>> that choice & case identifiers do *not* appear in:
>> - leafref paths
>> - must statements
>> - when statements
>> right?
> 
> Yup.
> 
> Lada
> 
>>
>> (they *do* appear in augment paths though since that definitely needs to 
>> refer
>> to schema)

They also appear in 'deviation' and 'refine' paths, which unlike augment
paths can identify a leaf or leaf-list (although 'refine' is of course
only relevant for nodes in a (top-level) grouping).

--Per

>> Jason
>>
>>> -Original Message-
>>> From: Ladislav Lhotka 
>>> Sent: Thursday, November 22, 2018 10:28 AM
>>> To: Martin Bjorklund 
>>> Cc: a...@yumaworks.com; Sterne, Jason (Nokia - CA/Ottawa)
>>> ; netmod@ietf.org
>>> Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC
>>> change?
>>>
>>> On Thu, 2018-11-22 at 16:14 +0100, Martin Bjorklund wrote:
>>>> Ladislav Lhotka  wrote:
>>>>> On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
>>>>>> Andy Bierman  wrote:
>>>>>>> On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund 
>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>>> Andy Bierman  writes:
>>>>>>>>>
>>>>>>>>>> On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia -
>>> CA/Ottawa)
>>>> <
>>>>>>>>>> jason.ste...@nokia.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If we have a YANG model with a leaf:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> MODEL VERSION 1:
>>>>>>>>>>>
>>>>>>>>>>> container my-model {
>>>>>>>>>>>
>>>>>>>>>>> leaf a { type string; }
>>>>>>>>>>>
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> And then later we produce another version of the model where
>>> that
>>>>>>>> leaf is
>>>>>>>>>>> placed into a choice construct:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> MODEL VERSION 2:
>>>>>>>>>>>
>>>>>>>>>>> container my-model {
>>>>>>>>>>>
>>>>>>>>>>> choice some-choice {
>>>>>>>>>>>
>>>>>>>>>>> case x {
>>>>>>>>>>>
>>>>>>>>>>> leaf a { type string; }
>>>>>>>>>>>
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Is that considered a non-backwards-compatible change?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> yes -- even though the data node /my-model/x did not change,
>>>>>>>>>> the schema node /my-model/a changed to /my-model/some-
>>> choice/x/a.
>>>>>>>>>> Any leafref path pointing at this leaf will break.
>>>>>>>>>
>>>>>>>>> This is not correct. A leafref path is a special XPath, and as
>>>>>>>>> such
>>>>>>>>> includes only data nodes, i.e. NOT choice and case nodes.
>

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Ladislav Lhotka]

On Thu, 2018-11-22 at 15:31 +, Sterne, Jason (Nokia - CA/Ottawa) wrote:
> From what I can understand below, none of this debate affects the conclusion
> that choice & case identifiers do *not* appear in:
> - leafref paths
> - must statements
> - when statements
> right?

Yup.

Lada

> 
> (they *do* appear in augment paths though since that definitely needs to refer
> to schema)
> 
> Jason
> 
> > -Original Message-
> > From: Ladislav Lhotka 
> > Sent: Thursday, November 22, 2018 10:28 AM
> > To: Martin Bjorklund 
> > Cc: a...@yumaworks.com; Sterne, Jason (Nokia - CA/Ottawa)
> > ; netmod@ietf.org
> > Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC
> > change?
> > 
> > On Thu, 2018-11-22 at 16:14 +0100, Martin Bjorklund wrote:
> > > Ladislav Lhotka  wrote:
> > > > On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
> > > > > Andy Bierman  wrote:
> > > > > > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund 
> > wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Ladislav Lhotka  wrote:
> > > > > > > > Andy Bierman  writes:
> > > > > > > > 
> > > > > > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia -
> > CA/Ottawa)
> > > <
> > > > > > > > > jason.ste...@nokia.com> wrote:
> > > > > > > > > 
> > > > > > > > > > Hi all,
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > If we have a YANG model with a leaf:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > MODEL VERSION 1:
> > > > > > > > > > 
> > > > > > > > > > container my-model {
> > > > > > > > > > 
> > > > > > > > > > leaf a { type string; }
> > > > > > > > > > 
> > > > > > > > > > }
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > And then later we produce another version of the model where
> > that
> > > > > > > leaf is
> > > > > > > > > > placed into a choice construct:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > MODEL VERSION 2:
> > > > > > > > > > 
> > > > > > > > > > container my-model {
> > > > > > > > > > 
> > > > > > > > > > choice some-choice {
> > > > > > > > > > 
> > > > > > > > > > case x {
> > > > > > > > > > 
> > > > > > > > > > leaf a { type string; }
> > > > > > > > > > 
> > > > > > > > > > }
> > > > > > > > > > 
> > > > > > > > > > }
> > > > > > > > > > 
> > > > > > > > > > }
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Is that considered a non-backwards-compatible change?
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > yes -- even though the data node /my-model/x did not change,
> > > > > > > > > the schema node /my-model/a changed to /my-model/some-
> > choice/x/a.
> > > > > > > > > Any leafref path pointing at this leaf will break.
> > > > > > > > 
> > > > > > > > This is not correct. A leafref path is a special XPath, and as
> > > > > > > > such
> > > > > > > > includes only data nodes, i.e. NOT choice and case nodes.
> > > > > > > > 
> > > > > > &

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Sterne, Jason (Nokia - CA/Ottawa)]

>From what I can understand below, none of this debate affects the conclusion 
>that choice & case identifiers do *not* appear in:
- leafref paths
- must statements
- when statements
right?

(they *do* appear in augment paths though since that definitely needs to refer 
to schema)

Jason

> -Original Message-
> From: Ladislav Lhotka 
> Sent: Thursday, November 22, 2018 10:28 AM
> To: Martin Bjorklund 
> Cc: a...@yumaworks.com; Sterne, Jason (Nokia - CA/Ottawa)
> ; netmod@ietf.org
> Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC
> change?
> 
> On Thu, 2018-11-22 at 16:14 +0100, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
> > > > Andy Bierman  wrote:
> > > > > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund 
> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Ladislav Lhotka  wrote:
> > > > > > > Andy Bierman  writes:
> > > > > > >
> > > > > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia -
> CA/Ottawa)
> > <
> > > > > > > > jason.ste...@nokia.com> wrote:
> > > > > > > >
> > > > > > > >> Hi all,
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> If we have a YANG model with a leaf:
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> MODEL VERSION 1:
> > > > > > > >>
> > > > > > > >> container my-model {
> > > > > > > >>
> > > > > > > >> leaf a { type string; }
> > > > > > > >>
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> And then later we produce another version of the model where
> that
> > > > > > leaf is
> > > > > > > >> placed into a choice construct:
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> MODEL VERSION 2:
> > > > > > > >>
> > > > > > > >> container my-model {
> > > > > > > >>
> > > > > > > >> choice some-choice {
> > > > > > > >>
> > > > > > > >> case x {
> > > > > > > >>
> > > > > > > >> leaf a { type string; }
> > > > > > > >>
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Is that considered a non-backwards-compatible change?
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > > yes -- even though the data node /my-model/x did not change,
> > > > > > > > the schema node /my-model/a changed to /my-model/some-
> choice/x/a.
> > > > > > > > Any leafref path pointing at this leaf will break.
> > > > > > >
> > > > > > > This is not correct. A leafref path is a special XPath, and as 
> > > > > > > such
> > > > > > > includes only data nodes, i.e. NOT choice and case nodes.
> > > > > > >
> > > > > > > What does change are schema node identifier. This could be
> > significant
> > > > > > > in an augment statement, but not ini this example because a leaf
> > cannot
> > > > > > > be augmented anyway.
> > > > > > >
> > > > > > > I don't see anything else that could break, so Jason's change 
> > > > > > > seems
> > > > > > > backward compatible to me.
> > > > > >
> > > &

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Ladislav Lhotka]

On Thu, 2018-11-22 at 16:14 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
> > > Andy Bierman  wrote:
> > > > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund  
> > > > wrote:
> > > > 
> > > > > Hi,
> > > > >
> > > > > Ladislav Lhotka  wrote:
> > > > > > Andy Bierman  writes:
> > > > > >
> > > > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa)
> <
> > > > > > > jason.ste...@nokia.com> wrote:
> > > > > > >
> > > > > > >> Hi all,
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> If we have a YANG model with a leaf:
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> MODEL VERSION 1:
> > > > > > >>
> > > > > > >> container my-model {
> > > > > > >>
> > > > > > >> leaf a { type string; }
> > > > > > >>
> > > > > > >> }
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> And then later we produce another version of the model where that
> > > > > leaf is
> > > > > > >> placed into a choice construct:
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> MODEL VERSION 2:
> > > > > > >>
> > > > > > >> container my-model {
> > > > > > >>
> > > > > > >> choice some-choice {
> > > > > > >>
> > > > > > >> case x {
> > > > > > >>
> > > > > > >> leaf a { type string; }
> > > > > > >>
> > > > > > >> }
> > > > > > >>
> > > > > > >> }
> > > > > > >>
> > > > > > >> }
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> Is that considered a non-backwards-compatible change?
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > > yes -- even though the data node /my-model/x did not change,
> > > > > > > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > > > > > > Any leafref path pointing at this leaf will break.
> > > > > >
> > > > > > This is not correct. A leafref path is a special XPath, and as such
> > > > > > includes only data nodes, i.e. NOT choice and case nodes.
> > > > > >
> > > > > > What does change are schema node identifier. This could be
> significant
> > > > > > in an augment statement, but not ini this example because a leaf
> cannot
> > > > > > be augmented anyway.
> > > > > >
> > > > > > I don't see anything else that could break, so Jason's change seems
> > > > > > backward compatible to me.
> > > > >
> > > > > Since it does change the schema tree, this is not legal according to
> > > > > 7950.  So in that sense it is not backwards compatible.  The rules in
> > > > > 7950 protect both clients and other modules that import the module.
> > > > >
> > > > >
> > > > This text is confusing wrt/ schema tree vs data tree:
> > > > 
> > > > 
> > > > 9.9 ;;.  The leafref
> > > > Built-In Type
> > > > 
> > > >The leafref built-in type is restricted to the value space of some
> > > >leaf or leaf-list node in the schema tree and optionally further
> > > >restricted by corresponding instance nodes in the data tree.  The
> > > >"path" substatement (Section 9.9.2
> > > > ;;) is used to
> > > > identify the referred
> > > >leaf or leaf-list node in the schema tree.  The value space of the
> > > >referring node is the value space of the referred node.
> > > 
> > > Yes, it should be "data tree" in both occurrences.
> > 
> > I tend to disagree. The values of a leafref are first restricted according
> to
> > the *schema*, i.e. even before any leaf instance exists in the data tree
> that
> > the leafref can point to. Consider this example:
> > 
> > list map {
> >   key name;
> >   leaf name {
> > type string;
> >   }
> >   leaf value {
> > type uint8;
> >   }
> > }
> > leaf link {
> >   type leafref {
> > path "../map[name='quux']/value";
> > default "foo";
> >   }
> > }
> > 
> > We had a long discussion about this, maybe I could find it, and the
> conclusion
> > was that a YANG parser should flag the default "foo" value as incorrect even
> > before any instance data are in sight.
> 
> Yes, this is correct.  The quoted text needs to be rewritten to make
> this more clear.  Altough the path refers to a (potential) node in the
> data tree, that node obviously has a node in the schema tree, and its
> value space restricts the value space of the leafref node.
> 
> > I wasn't exactly happy with this conclusion because it assumes that we can
> use
> > the XPath from the argument of "path" to locate the *schema node* and check
> its
> > type. Although it looks appealing (everybody sees what the type of "value"
> is,
> > right?), I think this is just another unfortunate example of mixing up the
> > schema and data instances.
> > 
> > Let me ask: can we expect a newcomer to understand what's going on if even
> > seasoned YANG doctors get confused?
> 
> Yes.
> 
> I've been told that people don't read documentation or specifications
> and just look at examples.

The problem with examples is that they have to 

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
> > Andy Bierman  wrote:
> > > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund  wrote:
> > > 
> > > > Hi,
> > > >
> > > > Ladislav Lhotka  wrote:
> > > > > Andy Bierman  writes:
> > > > >
> > > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> > > > > > jason.ste...@nokia.com> wrote:
> > > > > >
> > > > > >> Hi all,
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> If we have a YANG model with a leaf:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> MODEL VERSION 1:
> > > > > >>
> > > > > >> container my-model {
> > > > > >>
> > > > > >> leaf a { type string; }
> > > > > >>
> > > > > >> }
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> And then later we produce another version of the model where that
> > > > leaf is
> > > > > >> placed into a choice construct:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> MODEL VERSION 2:
> > > > > >>
> > > > > >> container my-model {
> > > > > >>
> > > > > >> choice some-choice {
> > > > > >>
> > > > > >> case x {
> > > > > >>
> > > > > >> leaf a { type string; }
> > > > > >>
> > > > > >> }
> > > > > >>
> > > > > >> }
> > > > > >>
> > > > > >> }
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> Is that considered a non-backwards-compatible change?
> > > > > >>
> > > > > >
> > > > > >
> > > > > > yes -- even though the data node /my-model/x did not change,
> > > > > > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > > > > > Any leafref path pointing at this leaf will break.
> > > > >
> > > > > This is not correct. A leafref path is a special XPath, and as such
> > > > > includes only data nodes, i.e. NOT choice and case nodes.
> > > > >
> > > > > What does change are schema node identifier. This could be significant
> > > > > in an augment statement, but not ini this example because a leaf 
> > > > > cannot
> > > > > be augmented anyway.
> > > > >
> > > > > I don't see anything else that could break, so Jason's change seems
> > > > > backward compatible to me.
> > > >
> > > > Since it does change the schema tree, this is not legal according to
> > > > 7950.  So in that sense it is not backwards compatible.  The rules in
> > > > 7950 protect both clients and other modules that import the module.
> > > >
> > > >
> > > This text is confusing wrt/ schema tree vs data tree:
> > > 
> > > 
> > > 9.9 ;.  The leafref
> > > Built-In Type
> > > 
> > >The leafref built-in type is restricted to the value space of some
> > >leaf or leaf-list node in the schema tree and optionally further
> > >restricted by corresponding instance nodes in the data tree.  The
> > >"path" substatement (Section 9.9.2
> > > ;) is used to
> > > identify the referred
> > >leaf or leaf-list node in the schema tree.  The value space of the
> > >referring node is the value space of the referred node.
> > 
> > Yes, it should be "data tree" in both occurrences.
> 
> I tend to disagree. The values of a leafref are first restricted according to
> the *schema*, i.e. even before any leaf instance exists in the data tree that
> the leafref can point to. Consider this example:
> 
> list map {
>   key name;
>   leaf name {
> type string;
>   }
>   leaf value {
> type uint8;
>   }
> }
> leaf link {
>   type leafref {
> path "../map[name='quux']/value";
> default "foo";
>   }
> }
> 
> We had a long discussion about this, maybe I could find it, and the conclusion
> was that a YANG parser should flag the default "foo" value as incorrect even
> before any instance data are in sight.

Yes, this is correct.  The quoted text needs to be rewritten to make
this more clear.  Altough the path refers to a (potential) node in the
data tree, that node obviously has a node in the schema tree, and its
value space restricts the value space of the leafref node.

> I wasn't exactly happy with this conclusion because it assumes that we can use
> the XPath from the argument of "path" to locate the *schema node* and check 
> its
> type. Although it looks appealing (everybody sees what the type of "value" is,
> right?), I think this is just another unfortunate example of mixing up the
> schema and data instances.
> 
> Let me ask: can we expect a newcomer to understand what's going on if even
> seasoned YANG doctors get confused?

Yes.

I've been told that people don't read documentation or specifications
and just look at examples.



/martin

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Ladislav Lhotka]

On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
> Andy Bierman  wrote:
> > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund  wrote:
> > 
> > > Hi,
> > >
> > > Ladislav Lhotka  wrote:
> > > > Andy Bierman  writes:
> > > >
> > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> > > > > jason.ste...@nokia.com> wrote:
> > > > >
> > > > >> Hi all,
> > > > >>
> > > > >>
> > > > >>
> > > > >> If we have a YANG model with a leaf:
> > > > >>
> > > > >>
> > > > >>
> > > > >> MODEL VERSION 1:
> > > > >>
> > > > >> container my-model {
> > > > >>
> > > > >> leaf a { type string; }
> > > > >>
> > > > >> }
> > > > >>
> > > > >>
> > > > >>
> > > > >> And then later we produce another version of the model where that
> > > leaf is
> > > > >> placed into a choice construct:
> > > > >>
> > > > >>
> > > > >>
> > > > >> MODEL VERSION 2:
> > > > >>
> > > > >> container my-model {
> > > > >>
> > > > >> choice some-choice {
> > > > >>
> > > > >> case x {
> > > > >>
> > > > >> leaf a { type string; }
> > > > >>
> > > > >> }
> > > > >>
> > > > >> }
> > > > >>
> > > > >> }
> > > > >>
> > > > >>
> > > > >>
> > > > >> Is that considered a non-backwards-compatible change?
> > > > >>
> > > > >
> > > > >
> > > > > yes -- even though the data node /my-model/x did not change,
> > > > > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > > > > Any leafref path pointing at this leaf will break.
> > > >
> > > > This is not correct. A leafref path is a special XPath, and as such
> > > > includes only data nodes, i.e. NOT choice and case nodes.
> > > >
> > > > What does change are schema node identifier. This could be significant
> > > > in an augment statement, but not ini this example because a leaf cannot
> > > > be augmented anyway.
> > > >
> > > > I don't see anything else that could break, so Jason's change seems
> > > > backward compatible to me.
> > >
> > > Since it does change the schema tree, this is not legal according to
> > > 7950.  So in that sense it is not backwards compatible.  The rules in
> > > 7950 protect both clients and other modules that import the module.
> > >
> > >
> > This text is confusing wrt/ schema tree vs data tree:
> > 
> > 
> > 9.9 ;.  The leafref
> > Built-In Type
> > 
> >The leafref built-in type is restricted to the value space of some
> >leaf or leaf-list node in the schema tree and optionally further
> >restricted by corresponding instance nodes in the data tree.  The
> >"path" substatement (Section 9.9.2
> > ;) is used to
> > identify the referred
> >leaf or leaf-list node in the schema tree.  The value space of the
> >referring node is the value space of the referred node.
> 
> Yes, it should be "data tree" in both occurrences.

I tend to disagree. The values of a leafref are first restricted according to
the *schema*, i.e. even before any leaf instance exists in the data tree that
the leafref can point to. Consider this example:

list map {
  key name;
  leaf name {
type string;
  }
  leaf value {
type uint8;
  }
}
leaf link {
  type leafref {
path "../map[name='quux']/value";
default "foo";
  }
}

We had a long discussion about this, maybe I could find it, and the conclusion
was that a YANG parser should flag the default "foo" value as incorrect even
before any instance data are in sight.

I wasn't exactly happy with this conclusion because it assumes that we can use
the XPath from the argument of "path" to locate the *schema node* and check its
type. Although it looks appealing (everybody sees what the type of "value" is,
right?), I think this is just another unfortunate example of mixing up the
schema and data instances.

Let me ask: can we expect a newcomer to understand what's going on if even
seasoned YANG doctors get confused?

Lada 

> 
> 
> 
> /martin
> 
> 
> > 
> > 
> > 
> > 
> > 
> > >
> > > /martin
> > >
> > >
> > 
> > Andy
> > 
> > 
> > >
> > >
> > > >
> > > > Lada
> > > >
> > > > >
> > > > >
> > > > > Andy
> > > > >
> > > > >
> > > > >>
> > > > >> Does the answer depend on whether the choice contains other cases (or
> > > > >> other cases that are the default case)?
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > > no
> > > > >
> > > > >
> > > > >> MODEL VERSION 3:
> > > > >>
> > > > >> container my-model {
> > > > >>
> > > > >> choice some-choice {
> > > > >>
> > > > >> case x {
> > > > >>
> > > > >> leaf a { type string; }
> > > > >>
> > > > >> }
> > > > >>
> > > > >> case y {
> > > > >>
> > > > >> leaf b { type string; }
> > > > >>
> > > > >> }
> > > > >>
> > > > >> }
> > > > >>
> > > > >> }
> > > > >>
> > > > >>
> > > > >>
> > > > >> A client 'foo' using VERSION 1 would still be able to set & read back
> > > leaf
> > > > >> a in the same way as it always did.
> > > > >>
> > > > >>
> > > > 

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Ladislav Lhotka]

On Thu, 2018-11-22 at 15:01 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Thu, 2018-11-22 at 14:39 +0100, Martin Bjorklund wrote:
> > > Hi,
> > > 
> > > Ladislav Lhotka  wrote:
> > > > Andy Bierman  writes:
> > > > 
> > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> > > > > jason.ste...@nokia.com> wrote:
> > > > >
> > > > >> Hi all,
> > > > >>
> > > > >>
> > > > >>
> > > > >> If we have a YANG model with a leaf:
> > > > >>
> > > > >>
> > > > >>
> > > > >> MODEL VERSION 1:
> > > > >>
> > > > >> container my-model {
> > > > >>
> > > > >> leaf a { type string; }
> > > > >>
> > > > >> }
> > > > >>
> > > > >>
> > > > >>
> > > > >> And then later we produce another version of the model where that
> leaf is
> > > > >> placed into a choice construct:
> > > > >>
> > > > >>
> > > > >>
> > > > >> MODEL VERSION 2:
> > > > >>
> > > > >> container my-model {
> > > > >>
> > > > >> choice some-choice {
> > > > >>
> > > > >> case x {
> > > > >>
> > > > >> leaf a { type string; }
> > > > >>
> > > > >> }
> > > > >>
> > > > >> }
> > > > >>
> > > > >> }
> > > > >>
> > > > >>
> > > > >>
> > > > >> Is that considered a non-backwards-compatible change?
> > > > >>
> > > > >
> > > > >
> > > > > yes -- even though the data node /my-model/x did not change,
> > > > > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > > > > Any leafref path pointing at this leaf will break.
> > > > 
> > > > This is not correct. A leafref path is a special XPath, and as such
> > > > includes only data nodes, i.e. NOT choice and case nodes.
> > > > 
> > > > What does change are schema node identifier. This could be significant
> > > > in an augment statement, but not ini this example because a leaf cannot
> > > > be augmented anyway.
> > > > 
> > > > I don't see anything else that could break, so Jason's change seems
> > > > backward compatible to me.
> > > 
> > > Since it does change the schema tree, this is not legal according to
> > > 7950.  So in that sense it is not backwards compatible.  The rules in
> > > 7950 protect both clients and other modules that import the module.
> > 
> > Section 11 does not explicitly forbid changes that change schema node
> > identifiers. On the other hand, it contains this item:
> > 
> >o  Any set of data definition nodes may be replaced with another set
> >   of syntactically and semantically equivalent nodes.  For example,
> >   a set of leafs may be replaced by a "uses" statement of a grouping
> >   with the same leafs.
> 
> But moving nodes into a grouping that is used doesn't change the
> schema tree.

The grouping is mentioned there as an example.

> 
> 
> > I think this applies nicely to the current case: the modified schema
> > is arguably
> > semantically equivalent to the old one.
> 
> But not syntactically (in the schema tree).

Well, "syntactically equivalent" is not defined in RFC 7950, and intuitively it
is not clear at all that it means "the same schema tree". In fact, the example
with a grouping leads to a different abstract syntax tree for the YANG module,
so one could also argue that it is not syntactically equivalent.

"Semantically equivalent" makes more sense: schemas A and B are semantically
equivalent if all data trees valid against A are also valid against B, and vice
versa.

Lada 

> 
> 
> /martin
> 
> 
> > 
> > Lada
> > 
> > 
> > > 
> > > 
> > > /martin
> > > 
> > > 
> > > 
> > > > 
> > > > Lada
> > > > 
> > > > >
> > > > >
> > > > > Andy
> > > > >
> > > > >
> > > > >>
> > > > >> Does the answer depend on whether the choice contains other cases (or
> > > > >> other cases that are the default case)?
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > > no
> > > > >
> > > > >
> > > > >> MODEL VERSION 3:
> > > > >>
> > > > >> container my-model {
> > > > >>
> > > > >> choice some-choice {
> > > > >>
> > > > >> case x {
> > > > >>
> > > > >> leaf a { type string; }
> > > > >>
> > > > >> }
> > > > >>
> > > > >> case y {
> > > > >>
> > > > >> leaf b { type string; }
> > > > >>
> > > > >> }
> > > > >>
> > > > >> }
> > > > >>
> > > > >> }
> > > > >>
> > > > >>
> > > > >>
> > > > >> A client 'foo' using VERSION 1 would still be able to set & read back
> > > leaf
> > > > >> a in the same way as it always did.
> > > > >>
> > > > >>
> > > > >>
> > > > >> But if another client 'bar' (using VERSION 3) sets leaf 'b', then
> leaf
> > > 'a'
> > > > >> would disappear. That could be surprising to client 'foo' although
> > > perhaps
> > > > >> no more surprising than if another client simply deletes leaf 'a'
> (using
> > > > >> VERSION 1).
> > > > >>
> > > > >>
> > > > >>
> > > > >> Jason
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> ___
> > > > >> netmod mailing list
> > > > >> netmod@ietf.org
> > > > >> https://www.ietf.org/mailman/listinfo/netmod
> > > 

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Martin Bjorklund]

Andy Bierman  wrote:
> On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > Ladislav Lhotka  wrote:
> > > Andy Bierman  writes:
> > >
> > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> > > > jason.ste...@nokia.com> wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >>
> > > >>
> > > >> If we have a YANG model with a leaf:
> > > >>
> > > >>
> > > >>
> > > >> MODEL VERSION 1:
> > > >>
> > > >> container my-model {
> > > >>
> > > >> leaf a { type string; }
> > > >>
> > > >> }
> > > >>
> > > >>
> > > >>
> > > >> And then later we produce another version of the model where that
> > leaf is
> > > >> placed into a choice construct:
> > > >>
> > > >>
> > > >>
> > > >> MODEL VERSION 2:
> > > >>
> > > >> container my-model {
> > > >>
> > > >> choice some-choice {
> > > >>
> > > >> case x {
> > > >>
> > > >> leaf a { type string; }
> > > >>
> > > >> }
> > > >>
> > > >> }
> > > >>
> > > >> }
> > > >>
> > > >>
> > > >>
> > > >> Is that considered a non-backwards-compatible change?
> > > >>
> > > >
> > > >
> > > > yes -- even though the data node /my-model/x did not change,
> > > > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > > > Any leafref path pointing at this leaf will break.
> > >
> > > This is not correct. A leafref path is a special XPath, and as such
> > > includes only data nodes, i.e. NOT choice and case nodes.
> > >
> > > What does change are schema node identifier. This could be significant
> > > in an augment statement, but not ini this example because a leaf cannot
> > > be augmented anyway.
> > >
> > > I don't see anything else that could break, so Jason's change seems
> > > backward compatible to me.
> >
> > Since it does change the schema tree, this is not legal according to
> > 7950.  So in that sense it is not backwards compatible.  The rules in
> > 7950 protect both clients and other modules that import the module.
> >
> >
> This text is confusing wrt/ schema tree vs data tree:
> 
> 
> 9.9 .  The leafref
> Built-In Type
> 
>The leafref built-in type is restricted to the value space of some
>leaf or leaf-list node in the schema tree and optionally further
>restricted by corresponding instance nodes in the data tree.  The
>"path" substatement (Section 9.9.2
> ) is used to
> identify the referred
>leaf or leaf-list node in the schema tree.  The value space of the
>referring node is the value space of the referred node.

Yes, it should be "data tree" in both occurrences.



/martin


> 
> 
> 
> 
> 
> >
> > /martin
> >
> >
> 
> Andy
> 
> 
> >
> >
> > >
> > > Lada
> > >
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > >>
> > > >> Does the answer depend on whether the choice contains other cases (or
> > > >> other cases that are the default case)?
> > > >>
> > > >>
> > > >>
> > > >
> > > > no
> > > >
> > > >
> > > >> MODEL VERSION 3:
> > > >>
> > > >> container my-model {
> > > >>
> > > >> choice some-choice {
> > > >>
> > > >> case x {
> > > >>
> > > >> leaf a { type string; }
> > > >>
> > > >> }
> > > >>
> > > >> case y {
> > > >>
> > > >> leaf b { type string; }
> > > >>
> > > >> }
> > > >>
> > > >> }
> > > >>
> > > >> }
> > > >>
> > > >>
> > > >>
> > > >> A client 'foo' using VERSION 1 would still be able to set & read back
> > leaf
> > > >> a in the same way as it always did.
> > > >>
> > > >>
> > > >>
> > > >> But if another client 'bar' (using VERSION 3) sets leaf 'b', then
> > leaf 'a'
> > > >> would disappear. That could be surprising to client 'foo' although
> > perhaps
> > > >> no more surprising than if another client simply deletes leaf 'a'
> > (using
> > > >> VERSION 1).
> > > >>
> > > >>
> > > >>
> > > >> Jason
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> ___
> > > >> netmod mailing list
> > > >> netmod@ietf.org
> > > >> https://www.ietf.org/mailman/listinfo/netmod
> > > >>
> > > > ___
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > >
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> >

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Ladislav Lhotka]

On Thu, 2018-11-22 at 14:39 +0100, Martin Bjorklund wrote:
> Hi,
> 
> Ladislav Lhotka  wrote:
> > Andy Bierman  writes:
> > 
> > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> > > jason.ste...@nokia.com> wrote:
> > > 
> > > > Hi all,
> > > > 
> > > > 
> > > > 
> > > > If we have a YANG model with a leaf:
> > > > 
> > > > 
> > > > 
> > > > MODEL VERSION 1:
> > > > 
> > > > container my-model {
> > > > 
> > > > leaf a { type string; }
> > > > 
> > > > }
> > > > 
> > > > 
> > > > 
> > > > And then later we produce another version of the model where that leaf
> > > > is
> > > > placed into a choice construct:
> > > > 
> > > > 
> > > > 
> > > > MODEL VERSION 2:
> > > > 
> > > > container my-model {
> > > > 
> > > > choice some-choice {
> > > > 
> > > > case x {
> > > > 
> > > > leaf a { type string; }
> > > > 
> > > > }
> > > > 
> > > > }
> > > > 
> > > > }
> > > > 
> > > > 
> > > > 
> > > > Is that considered a non-backwards-compatible change?
> > > > 
> > > 
> > > yes -- even though the data node /my-model/x did not change,
> > > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > > Any leafref path pointing at this leaf will break.
> > 
> > This is not correct. A leafref path is a special XPath, and as such
> > includes only data nodes, i.e. NOT choice and case nodes.
> > 
> > What does change are schema node identifier. This could be significant
> > in an augment statement, but not ini this example because a leaf cannot
> > be augmented anyway.
> > 
> > I don't see anything else that could break, so Jason's change seems
> > backward compatible to me.
> 
> Since it does change the schema tree, this is not legal according to
> 7950.  So in that sense it is not backwards compatible.  The rules in
> 7950 protect both clients and other modules that import the module.

Section 11 does not explicitly forbid changes that change schema node
identifiers. On the other hand, it contains this item:

   o  Any set of data definition nodes may be replaced with another set
  of syntactically and semantically equivalent nodes.  For example,
  a set of leafs may be replaced by a "uses" statement of a grouping
  with the same leafs.

I think this applies nicely to the current case: the modified schema is arguably
semantically equivalent to the old one.

Lada


> 
> /martin
> 
> 
> 
> > Lada
> > 
> > > 
> > > Andy
> > > 
> > > 
> > > > Does the answer depend on whether the choice contains other cases (or
> > > > other cases that are the default case)?
> > > > 
> > > > 
> > > > 
> > > 
> > > no
> > > 
> > > 
> > > > MODEL VERSION 3:
> > > > 
> > > > container my-model {
> > > > 
> > > > choice some-choice {
> > > > 
> > > > case x {
> > > > 
> > > > leaf a { type string; }
> > > > 
> > > > }
> > > > 
> > > > case y {
> > > > 
> > > > leaf b { type string; }
> > > > 
> > > > }
> > > > 
> > > > }
> > > > 
> > > > }
> > > > 
> > > > 
> > > > 
> > > > A client 'foo' using VERSION 1 would still be able to set & read back
> leaf
> > > > a in the same way as it always did.
> > > > 
> > > > 
> > > > 
> > > > But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf
> 'a'
> > > > would disappear. That could be surprising to client 'foo' although
> perhaps
> > > > no more surprising than if another client simply deletes leaf 'a' (using
> > > > VERSION 1).
> > > > 
> > > > 
> > > > 
> > > > Jason
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > ___
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > 
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Andy Bierman]

On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund  wrote:

> Hi,
>
> Ladislav Lhotka  wrote:
> > Andy Bierman  writes:
> >
> > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> > > jason.ste...@nokia.com> wrote:
> > >
> > >> Hi all,
> > >>
> > >>
> > >>
> > >> If we have a YANG model with a leaf:
> > >>
> > >>
> > >>
> > >> MODEL VERSION 1:
> > >>
> > >> container my-model {
> > >>
> > >> leaf a { type string; }
> > >>
> > >> }
> > >>
> > >>
> > >>
> > >> And then later we produce another version of the model where that
> leaf is
> > >> placed into a choice construct:
> > >>
> > >>
> > >>
> > >> MODEL VERSION 2:
> > >>
> > >> container my-model {
> > >>
> > >> choice some-choice {
> > >>
> > >> case x {
> > >>
> > >> leaf a { type string; }
> > >>
> > >> }
> > >>
> > >> }
> > >>
> > >> }
> > >>
> > >>
> > >>
> > >> Is that considered a non-backwards-compatible change?
> > >>
> > >
> > >
> > > yes -- even though the data node /my-model/x did not change,
> > > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > > Any leafref path pointing at this leaf will break.
> >
> > This is not correct. A leafref path is a special XPath, and as such
> > includes only data nodes, i.e. NOT choice and case nodes.
> >
> > What does change are schema node identifier. This could be significant
> > in an augment statement, but not ini this example because a leaf cannot
> > be augmented anyway.
> >
> > I don't see anything else that could break, so Jason's change seems
> > backward compatible to me.
>
> Since it does change the schema tree, this is not legal according to
> 7950.  So in that sense it is not backwards compatible.  The rules in
> 7950 protect both clients and other modules that import the module.
>
>
This text is confusing wrt/ schema tree vs data tree:


9.9 .  The leafref
Built-In Type

   The leafref built-in type is restricted to the value space of some
   leaf or leaf-list node in the schema tree and optionally further
   restricted by corresponding instance nodes in the data tree.  The
   "path" substatement (Section 9.9.2
) is used to
identify the referred
   leaf or leaf-list node in the schema tree.  The value space of the
   referring node is the value space of the referred node.





>
> /martin
>
>

Andy


>
>
> >
> > Lada
> >
> > >
> > >
> > > Andy
> > >
> > >
> > >>
> > >> Does the answer depend on whether the choice contains other cases (or
> > >> other cases that are the default case)?
> > >>
> > >>
> > >>
> > >
> > > no
> > >
> > >
> > >> MODEL VERSION 3:
> > >>
> > >> container my-model {
> > >>
> > >> choice some-choice {
> > >>
> > >> case x {
> > >>
> > >> leaf a { type string; }
> > >>
> > >> }
> > >>
> > >> case y {
> > >>
> > >> leaf b { type string; }
> > >>
> > >> }
> > >>
> > >> }
> > >>
> > >> }
> > >>
> > >>
> > >>
> > >> A client 'foo' using VERSION 1 would still be able to set & read back
> leaf
> > >> a in the same way as it always did.
> > >>
> > >>
> > >>
> > >> But if another client 'bar' (using VERSION 3) sets leaf 'b', then
> leaf 'a'
> > >> would disappear. That could be surprising to client 'foo' although
> perhaps
> > >> no more surprising than if another client simply deletes leaf 'a'
> (using
> > >> VERSION 1).
> > >>
> > >>
> > >>
> > >> Jason
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> ___
> > >> netmod mailing list
> > >> netmod@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/netmod
> > >>
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Martin Bjorklund]

Hi,

Ladislav Lhotka  wrote:
> Andy Bierman  writes:
> 
> > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> > jason.ste...@nokia.com> wrote:
> >
> >> Hi all,
> >>
> >>
> >>
> >> If we have a YANG model with a leaf:
> >>
> >>
> >>
> >> MODEL VERSION 1:
> >>
> >> container my-model {
> >>
> >> leaf a { type string; }
> >>
> >> }
> >>
> >>
> >>
> >> And then later we produce another version of the model where that leaf is
> >> placed into a choice construct:
> >>
> >>
> >>
> >> MODEL VERSION 2:
> >>
> >> container my-model {
> >>
> >> choice some-choice {
> >>
> >> case x {
> >>
> >> leaf a { type string; }
> >>
> >> }
> >>
> >> }
> >>
> >> }
> >>
> >>
> >>
> >> Is that considered a non-backwards-compatible change?
> >>
> >
> >
> > yes -- even though the data node /my-model/x did not change,
> > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > Any leafref path pointing at this leaf will break.
> 
> This is not correct. A leafref path is a special XPath, and as such
> includes only data nodes, i.e. NOT choice and case nodes.
> 
> What does change are schema node identifier. This could be significant
> in an augment statement, but not ini this example because a leaf cannot
> be augmented anyway.
> 
> I don't see anything else that could break, so Jason's change seems
> backward compatible to me.

Since it does change the schema tree, this is not legal according to
7950.  So in that sense it is not backwards compatible.  The rules in
7950 protect both clients and other modules that import the module.


/martin



> 
> Lada
> 
> >
> >
> > Andy
> >
> >
> >>
> >> Does the answer depend on whether the choice contains other cases (or
> >> other cases that are the default case)?
> >>
> >>
> >>
> >
> > no
> >
> >
> >> MODEL VERSION 3:
> >>
> >> container my-model {
> >>
> >> choice some-choice {
> >>
> >> case x {
> >>
> >> leaf a { type string; }
> >>
> >> }
> >>
> >> case y {
> >>
> >> leaf b { type string; }
> >>
> >> }
> >>
> >> }
> >>
> >> }
> >>
> >>
> >>
> >> A client 'foo' using VERSION 1 would still be able to set & read back leaf
> >> a in the same way as it always did.
> >>
> >>
> >>
> >> But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf 'a'
> >> would disappear. That could be surprising to client 'foo' although perhaps
> >> no more surprising than if another client simply deletes leaf 'a' (using
> >> VERSION 1).
> >>
> >>
> >>
> >> Jason
> >>
> >>
> >>
> >>
> >>
> >>
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Martin Bjorklund]

Hi,

"Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> Thanks Andy.
> 
> I didn't realize that leafref paths would contain the choice & case
> names as segments of the path.

The choice and case nodes are not present in the leafref's path, since
it's an XPath expression that works on the data tree.

Section 9.9.2 says about the context:

   o  If the "path" statement is defined within a typedef, the context
  node is the leaf or leaf-list node in the data tree that
  references the typedef.

   o  Otherwise, the context node is the node in the data tree for which
  the "path" statement is defined.

Note that it says "data tree", not "schema tree".

Also, note how leafref can match on keys:

  path "/interface/interface[name=current()/../mgmt-if-name]/name";

This won't work in the schema tree.

> But now that you pointed that out it
> clarified what this meant in section 7.9 of RFC7950:
>The identifier is used to identify the choice
>node in the schema tree.  A choice node does not exist in the data
>tree.
> 
> Is the same thing true for XPaths in 'must' and 'when' expressions?
> Would those contain choice & case names when referring to a node? Or
> do those refer to the *data* tree rather than the *schema* tree?

All XPath evaluations are done towards a data tree.  So no choice or
state nodes are present there.


/martin

> I'm
> sure it is in there somewhere but I couldn't quite figure that out
> from looking around 7950.
> 
> Jason
> 
> From: Andy Bierman 
> Sent: Monday, November 19, 2018 3:54 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) 
> Cc: NetMod WG 
> Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' -
> NBC change?
> 
> 
> On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa)
> mailto:jason.ste...@nokia.com>> wrote:
> Hi all,
> 
> If we have a YANG model with a leaf:
> 
> MODEL VERSION 1:
> container my-model {
> leaf a { type string; }
> }
> 
> And then later we produce another version of the model where that leaf
> is placed into a choice construct:
> 
> MODEL VERSION 2:
> container my-model {
> choice some-choice {
> case x {
> leaf a { type string; }
> }
> }
> }
> 
> Is that considered a non-backwards-compatible change?
> 
> 
> yes -- even though the data node /my-model/x did not change,
> the schema node /my-model/a changed to /my-model/some-choice/x/a.
> Any leafref path pointing at this leaf will break.
> 
> 
> Andy
> 
> 
> Does the answer depend on whether the choice contains other cases (or
> other cases that are the default case)?
> 
> 
> no
> 
> MODEL VERSION 3:
> container my-model {
> choice some-choice {
> case x {
> leaf a { type string; }
> }
> case y {
> leaf b { type string; }
> }
> }
> }
> 
> A client 'foo' using VERSION 1 would still be able to set & read back
> leaf a in the same way as it always did.
> 
> But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf
> 'a' would disappear. That could be surprising to client 'foo' although
> perhaps no more surprising than if another client simply deletes leaf
> 'a' (using VERSION 1).
> 
> Jason
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org<mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Ladislav Lhotka]

Andy Bierman  writes:

> On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> jason.ste...@nokia.com> wrote:
>
>> Hi all,
>>
>>
>>
>> If we have a YANG model with a leaf:
>>
>>
>>
>> MODEL VERSION 1:
>>
>> container my-model {
>>
>> leaf a { type string; }
>>
>> }
>>
>>
>>
>> And then later we produce another version of the model where that leaf is
>> placed into a choice construct:
>>
>>
>>
>> MODEL VERSION 2:
>>
>> container my-model {
>>
>> choice some-choice {
>>
>> case x {
>>
>> leaf a { type string; }
>>
>> }
>>
>> }
>>
>> }
>>
>>
>>
>> Is that considered a non-backwards-compatible change?
>>
>
>
> yes -- even though the data node /my-model/x did not change,
> the schema node /my-model/a changed to /my-model/some-choice/x/a.
> Any leafref path pointing at this leaf will break.

This is not correct. A leafref path is a special XPath, and as such
includes only data nodes, i.e. NOT choice and case nodes.

What does change are schema node identifier. This could be significant
in an augment statement, but not ini this example because a leaf cannot
be augmented anyway.

I don't see anything else that could break, so Jason's change seems
backward compatible to me.

Lada

>
>
> Andy
>
>
>>
>> Does the answer depend on whether the choice contains other cases (or
>> other cases that are the default case)?
>>
>>
>>
>
> no
>
>
>> MODEL VERSION 3:
>>
>> container my-model {
>>
>> choice some-choice {
>>
>> case x {
>>
>> leaf a { type string; }
>>
>> }
>>
>> case y {
>>
>> leaf b { type string; }
>>
>> }
>>
>> }
>>
>> }
>>
>>
>>
>> A client 'foo' using VERSION 1 would still be able to set & read back leaf
>> a in the same way as it always did.
>>
>>
>>
>> But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf 'a'
>> would disappear. That could be surprising to client 'foo' although perhaps
>> no more surprising than if another client simply deletes leaf 'a' (using
>> VERSION 1).
>>
>>
>>
>> Jason
>>
>>
>>
>>
>>
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Sterne, Jason (Nokia - CA/Ottawa)]

Thanks Andy.

I didn't realize that leafref paths would contain the choice & case names as 
segments of the path. But now that you pointed that out it clarified what this 
meant in section 7.9 of RFC7950:
   The identifier is used to identify the choice
   node in the schema tree.  A choice node does not exist in the data
   tree.

Is the same thing true for XPaths in 'must' and 'when' expressions? Would those 
contain choice & case names when referring to a node? Or do those refer to the 
*data* tree rather than the *schema* tree?  I'm sure it is in there somewhere 
but I couldn't quite figure that out from looking around 7950.

Jason

From: Andy Bierman 
Sent: Monday, November 19, 2018 3:54 PM
To: Sterne, Jason (Nokia - CA/Ottawa) 
Cc: NetMod WG 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC 
change?


On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) 
mailto:jason.ste...@nokia.com>> wrote:
Hi all,

If we have a YANG model with a leaf:

MODEL VERSION 1:
container my-model {
leaf a { type string; }
}

And then later we produce another version of the model where that leaf is 
placed into a choice construct:

MODEL VERSION 2:
container my-model {
choice some-choice {
case x {
leaf a { type string; }
}
}
}

Is that considered a non-backwards-compatible change?


yes -- even though the data node /my-model/x did not change,
the schema node /my-model/a changed to /my-model/some-choice/x/a.
Any leafref path pointing at this leaf will break.


Andy


Does the answer depend on whether the choice contains other cases (or other 
cases that are the default case)?


no

MODEL VERSION 3:
container my-model {
choice some-choice {
case x {
leaf a { type string; }
}
case y {
leaf b { type string; }
}
}
}

A client 'foo' using VERSION 1 would still be able to set & read back leaf a in 
the same way as it always did.

But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf 'a' 
would disappear. That could be surprising to client 'foo' although perhaps no 
more surprising than if another client simply deletes leaf 'a' (using VERSION 
1).

Jason



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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Martin Bjorklund]

Martin Bjorklund  wrote:
> Hi,
> 
> "Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> > Hi all,
> > 
> > If we have a YANG model with a leaf:
> > 
> > MODEL VERSION 1:
> > container my-model {
> > leaf a { type string; }
> > }
> > 
> > And then later we produce another version of the model where that leaf
> > is placed into a choice construct:
> > 
> > MODEL VERSION 2:
> > container my-model {
> > choice some-choice {
> > case x {
> > leaf a { type string; }
> > }
> > }
> > }
> > 
> > Is that considered a non-backwards-compatible change?
> 
> Not accordning to current RFC 7950 rules, since it changes the schema
  ^

I meant, "Yes, accordning to current RFC 7950 rules this is not
allowed".   But I think you got that.


/martin

> node path (suppose the leaf was a container, and someone had augment
> /my-model/a).
> 
> > Does the answer depend on whether the choice contains other cases (or
> > other cases that are the default case)?
> 
> No.
> 
> > MODEL VERSION 3:
> > container my-model {
> > choice some-choice {
> > case x {
> > leaf a { type string; }
> > }
> > case y {
> > leaf b { type string; }
> > }
> > }
> > }
> > 
> > A client 'foo' using VERSION 1 would still be able to set & read back
> > leaf a in the same way as it always did.
> > 
> > But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf
> > 'a' would disappear. That could be surprising to client 'foo' although
> > perhaps no more surprising than if another client simply deletes leaf
> > 'a' (using VERSION 1).
> 
> 
> 
> /martin
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> 

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Andy Bierman]

On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
jason.ste...@nokia.com> wrote:

> Hi all,
>
>
>
> If we have a YANG model with a leaf:
>
>
>
> MODEL VERSION 1:
>
> container my-model {
>
> leaf a { type string; }
>
> }
>
>
>
> And then later we produce another version of the model where that leaf is
> placed into a choice construct:
>
>
>
> MODEL VERSION 2:
>
> container my-model {
>
> choice some-choice {
>
> case x {
>
> leaf a { type string; }
>
> }
>
> }
>
> }
>
>
>
> Is that considered a non-backwards-compatible change?
>


yes -- even though the data node /my-model/x did not change,
the schema node /my-model/a changed to /my-model/some-choice/x/a.
Any leafref path pointing at this leaf will break.


Andy


>
> Does the answer depend on whether the choice contains other cases (or
> other cases that are the default case)?
>
>
>

no


> MODEL VERSION 3:
>
> container my-model {
>
> choice some-choice {
>
> case x {
>
> leaf a { type string; }
>
> }
>
> case y {
>
> leaf b { type string; }
>
> }
>
> }
>
> }
>
>
>
> A client 'foo' using VERSION 1 would still be able to set & read back leaf
> a in the same way as it always did.
>
>
>
> But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf 'a'
> would disappear. That could be surprising to client 'foo' although perhaps
> no more surprising than if another client simply deletes leaf 'a' (using
> VERSION 1).
>
>
>
> Jason
>
>
>
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Sterne, Jason (Nokia - CA/Ottawa)]

Thanks. I forgot that the choice is in the *schema* path (was thinking about 
the instance data path which doesn't include the choice or case statements).

> -Original Message-
> From: Martin Bjorklund 
> Sent: Monday, November 19, 2018 3:46 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC
> change?
> 
> Hi,
> 
> "Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> > Hi all,
> >
> > If we have a YANG model with a leaf:
> >
> > MODEL VERSION 1:
> > container my-model {
> > leaf a { type string; }
> > }
> >
> > And then later we produce another version of the model where that leaf
> > is placed into a choice construct:
> >
> > MODEL VERSION 2:
> > container my-model {
> > choice some-choice {
> > case x {
> > leaf a { type string; }
> > }
> > }
> > }
> >
> > Is that considered a non-backwards-compatible change?
> 
> Not accordning to current RFC 7950 rules, since it changes the schema
> node path (suppose the leaf was a container, and someone had augment
> /my-model/a).
> 
> > Does the answer depend on whether the choice contains other cases (or
> > other cases that are the default case)?
> 
> No.
> 
> > MODEL VERSION 3:
> > container my-model {
> > choice some-choice {
> > case x {
> > leaf a { type string; }
> > }
> > case y {
> > leaf b { type string; }
> > }
> > }
> > }
> >
> > A client 'foo' using VERSION 1 would still be able to set & read back
> > leaf a in the same way as it always did.
> >
> > But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf
> > 'a' would disappear. That could be surprising to client 'foo' although
> > perhaps no more surprising than if another client simply deletes leaf
> > 'a' (using VERSION 1).
> 
> 
> 
> /martin

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

Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?

[Martin Bjorklund]

Hi,

"Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> Hi all,
> 
> If we have a YANG model with a leaf:
> 
> MODEL VERSION 1:
> container my-model {
> leaf a { type string; }
> }
> 
> And then later we produce another version of the model where that leaf
> is placed into a choice construct:
> 
> MODEL VERSION 2:
> container my-model {
> choice some-choice {
> case x {
> leaf a { type string; }
> }
> }
> }
> 
> Is that considered a non-backwards-compatible change?

Not accordning to current RFC 7950 rules, since it changes the schema
node path (suppose the leaf was a container, and someone had augment
/my-model/a).

> Does the answer depend on whether the choice contains other cases (or
> other cases that are the default case)?

No.

> MODEL VERSION 3:
> container my-model {
> choice some-choice {
> case x {
> leaf a { type string; }
> }
> case y {
> leaf b { type string; }
> }
> }
> }
> 
> A client 'foo' using VERSION 1 would still be able to set & read back
> leaf a in the same way as it always did.
> 
> But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf
> 'a' would disappear. That could be surprising to client 'foo' although
> perhaps no more surprising than if another client simply deletes leaf
> 'a' (using VERSION 1).



/martin

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