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

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 19 Nov 2018 20:31:55 +0000

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?

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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Nov 2018 21:46:22 +0100 (CET)

Hi,

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

> other cases that are the default case)?

No.

> 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

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 19 Nov 2018 20:47:40 +0000

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 <[email-masked]>
> Sent: Monday, November 19, 2018 3:46 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC
> change?
> 
> Hi,
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 19 Nov 2018 12:53:47 -0800

> 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

> other cases that are the default case)?

no

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 20 Nov 2018 08:33:59 +0100 (CET)

> 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

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 22 Nov 2018 12:54:27 +0000

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 <[email-masked]>
Sent: Monday, November 19, 2018 3:54 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
Cc: NetMod WG <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

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

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

Andy

no

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

Jason

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 22 Nov 2018 14:35:00 +0100

> 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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 22 Nov 2018 14:37:45 +0100 (CET)

Hi,

"Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]> 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:
> 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
> 
> On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa)
> <[email-masked]<mailto:[email-masked]>> wrote:
> Hi all,
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 22 Nov 2018 14:39:48 +0100 (CET)

Hi,

> 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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Nov 2018 05:52:53 -0800

On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund <[email-masked]> wrote:

> > >> 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; }
> > >>
> > >>         }
> > >>
> > >>     }
> > >>
> > >> }
> > >>
> > >>
> > >>
This text is confusing wrt/ schema tree vs data tree:

9.9 <https://tools.ietf.org/html/rfc7950#section-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
<https://tools.ietf.org/html/rfc7950#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.

Andy

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 22 Nov 2018 14:59:08 +0100

On Thu, 2018-11-22 at 14:39 +0100, Martin Bjorklund wrote:
> > > > And then later we produce another version of the model where that leaf
> > > > is

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

> 'a'

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 22 Nov 2018 15:00:27 +0100 (CET)

>    referring node is the value space of the referred node.

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

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 22 Nov 2018 15:26:12 +0100

On Thu, 2018-11-22 at 15:01 +0100, Martin Bjorklund wrote:
> But moving nodes into a grouping that is used doesn't change the
> schema tree.

The grouping is mentioned there as an example.

> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 22 Nov 2018 16:07:46 +0100

On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
> > 9.9 <https://tools.ietf.org/html/rfc7950#section-9.9>;.  The leafref
> > Built-In Type
> > 
> > <https://tools.ietf.org/html/rfc7950#section-9.9.2>;) is used to
> > identify the referred

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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 22 Nov 2018 16:14:38 +0100 (CET)

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

> seasoned YANG doctors get confused?

Yes.

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

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 22 Nov 2018 16:28:01 +0100

On Thu, 2018-11-22 at 16:14 +0100, Martin Bjorklund wrote:
> <
> > > > 9.9 <https://tools.ietf.org/html/rfc7950#section-9.9>;;.  The leafref
> > > > Built-In Type
> > > > 
> > > > <https://tools.ietf.org/html/rfc7950#section-9.9.2>;;) is used to
> > > > identify the referred

The problem with examples is that they have to stay at a trivial level where
everything looks obvious and nobody has to care about subtle details such as the
difference between XPath and schema node identifiers. Those who had to implement
the above logic for a general case will confirm that it is pretty tricky.

Lada

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 22 Nov 2018 15:31:42 +0000

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

> From: Ladislav Lhotka <[email-masked]>
> Sent: Thursday, November 22, 2018 10:28 AM
> To: Martin Bjorklund <[email-masked]>
> Cc: [email-masked]; Sterne, Jason (Nokia - CA/Ottawa)
> <[email-masked]>; [email-masked]
> > > 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,

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 22 Nov 2018 16:37:21 +0100

On Thu, 2018-11-22 at 15:31 +0000, 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

> > > > > > 9.9 <https://tools.ietf.org/html/rfc7950#section-9.9>;;;.  The
> > > > > > leafref
> > > > > > Built-In Type
> > > > > > 
> > > > > > <https://tools.ietf.org/html/rfc7950#section-9.9.2>;;;) is used to
> > > > > > identify the referred
> > > > I tend to disagree. The values of a leafref are first restricted
> > > > according
> > > to

---

From: Per Hedeland <[email-masked]>
Date: Thu, 22 Nov 2018 17:03:47 +0100

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

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 22 Nov 2018 08:10:38 -0800

On Thu, Nov 22, 2018 at 7:28 AM Ladislav Lhotka <[email-masked]> wrote:

> > > > > > > in an augment statement, but not ini this example because a
> leaf
> > cannot
> > > > > > > be augmented anyway.
> > > > > > >
> > > the *schema*, i.e. even before any leaf instance exists in the data
> tree
> > that
I seemed to have known path-stmt was the data tree when I wrote my code ;-)
Our compiler (and pyang) complains if the choice and case nodes are given.

Because of the rule that choice and case names cannot clash with the first
real children
the schema tree expression will always identify the same node as the data
tree
(so including choice and case names is more verbose but otherwise correct)

Lada

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Nov 2018 17:30:46 +0100

> 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         <https://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Nov 2018 10:22:11 +0100

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Nov 2018 10:38:13 +0100

> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Nov 2018 10:55:09 +0100

> used to identify the referred leaf or leaf-list node in the schema

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.

> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 23 Nov 2018 11:05:48 +0100 (CET)

> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Nov 2018 11:27:04 +0100

> tree, but there is no text that ties these together.

Agreed. Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Nov 2018 12:33:41 +0100

> 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

   "path" substatement (Section 9.9.2) is used to identify the referred

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Nov 2018 13:02:03 +0100

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

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Nov 2018 13:39:07 +0100

> 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'.
 
> With require-instance=false there needn't be any referenced data tree node.

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

> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Nov 2018 14:29:18 +0100

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

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

> 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

---

From: Robert Wilton <[email-masked]>
Date: Fri, 23 Nov 2018 13:37:20 +0000

> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 23 Nov 2018 15:09:23 +0100 (CET)

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

> If the data tree node doesn't exist, we cannot refer to the schema tree node

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

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

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

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 23 Nov 2018 16:23:21 +0100

> "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?

> It's pretty clear what the intention is, right?  So what are the right

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

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Nov 2018 16:59:22 +0100

> failed "when" expression? Does it still apply?

Why do you think it would not?

> If the data tree node doesn't exist, we cannot refer to the schema tree node

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?

> 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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Nov 2018 09:23:01 -0800

> referenced leaf or leaflist ..." and "value space of the referenced

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

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Nov 2018 22:00:45 +0100

>    whether the syntax is based on schema-node identifier or data-node

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

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 23 Nov 2018 15:52:40 -0800

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

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 27 Nov 2018 16:28:04 +0100

> 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