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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

> On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
>> Andy Bierman <andy@yumaworks.com> wrote:
>> > 
>> > 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.
>> 
>> 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         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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