Subject: [netmod] "unique" and "key" in nested lists

From: "Jernej Tuljak" <[email-masked]>
Date: Thu, 24 Nov 2016 10:34:37 +0100

Hi,

I'm not entirely sure, but RFC6110 may have a bug where it defines how @nma:key and @nma:unique are processed. It relies on preceding-sibling axis to enforce the uniqueness constraint for those. While this may work in non-nested lists, it does not work for nested ones. The RFC seems to assume that all list entries of any list are siblings, but this may not be the case.

RFC6110, Section 12.8 [1] 

   Assume this annotation attribute contains "k_1 k_2 ... k_n", i.e.,

   specifies n children of CONTELEM as list keys.  The annotation is

   then mapped to the following Schematron report:

   <sch:report test="CONDITION">

     Duplicate key of list "CONTELEM"

   </sch:report>

   where CONDITION has this form:

   preceding-sibling::CONTELEM[C_1 and C_2 and ... and C_n]

   Each sub-expression C_i, for i=1,2,...,n, specifies the condition for

   violated uniqueness of the key k_i, namely

   k_i=current()/k_i

Now consider the following module:

module nested-list-unique {

  namespace "org:example:uri";

  prefix "nlu";

  revision 2016-11-17;

  container devices {

    list device {

      key id;      

      leaf id {

        type uint64;

      }

      leaf name {

        type string;

      }

      container interfaces {

        list interface {

          key id;

          unique "name";

          leaf id {

            type uint64;

          }

          leaf name {

            type string;

          }

        }

      }

    }

  }

}

And the following instance:

  <devices xmlns="org:example:uri">

    <device>

      <id>1</id>

      <interfaces>

        <interface>

          <id>1</id>

          <name>foo</name>

        </interface>

      </interfaces>

    </device>

    <device>

      <id>2</id>

      <interfaces>

        <interface>

          <id>1</id>

          <name>foo</name>

        </interface>

      </interfaces>

    </device>

  </devices>

According to YANG (1 and 1.1), the second list entry of 'interface' list violates both key and unique constraints. I don't think RFC7950/RFC6020 text may be interpreted otherwise – it implies global uniqueness. This will not be detected by RFC6110 Schematron rules.

RFC7950, Section 7.8. [2]

   The "list" statement is used to define an interior data node in the
   schema tree.  A list node may exist in multiple instances in the data
   tree.  Each such instance is known as a list entry.

RFC7950, Section 7.8.2. [3]

   The combined values of all the leafs specified in the key are used to
   uniquely identify a list entry.

RFC7950, Section 7.8.3. [4]

   The "unique" constraint specifies that the combined values of all the
   leaf instances specified in the argument string, including leafs with
   default values, MUST be unique within all list entry instances in
   which all referenced leafs exist or have default values.

Am I interpreting RFC7950 correctly? What was the intention?

Also, while searching the archives for similar discussion, I stumbled upon one that discusses "unique" in nested lists [5]. It seems that there was WG consensus that "unique" schema node identifiers cannot target nodes in a nested list, yet I've found no text in either RFCs to enforce this. Why so? 

[1] - https://tools.ietf.org/html/rfc6110#section-12.8

[2] - https://tools.ietf.org/html/rfc7950#section-7.8 

[3] - https://tools.ietf.org/html/rfc7950#section-7.8.2

[4] - https://tools.ietf.org/html/rfc7950#section-7.8.3

[5] - https://www.ietf.org/mail-archive/web/netmod/current/msg02066.html

Jernej

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 24 Nov 2016 11:11:19 +0100

> On 24 Nov 2016, at 10:34, Jernej Tuljak <[email-masked]> wrote:
> 
> Hi,
>  
> According to YANG (1 and 1.1), the second list entry of 'interface' list violates both key and unique constraints. I don't think

IMO the uniqueness constraint is only applied to entries of the same list instance, i.e. siblings in XPath terms. So I think your example violates neither "key" nor "unique" constraint.  

> RFC7950/RFC6020 text may be interpreted otherwise – it implies global uniqueness.

Yes, may be, but I don't think it was the intention.

> This will not be detected by RFC6110 Schematron rules.
>  

Right, and in fact I used this feature in one of the ancient versions of ietf-routing. Back then I proposed to essentially use the definition from 6110 for dealing with such cases, but this was not accepted.

Lada

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

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

---

From: "Jernej Tuljak" <[email-masked]>
Date: Thu, 24 Nov 2016 11:26:16 +0100

> -----Original Message-----
> From: Ladislav Lhotka [mailto:[email-masked]]
> Sent: Thursday, November 24, 2016 11:11 AM
> To: Jernej Tuljak <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [netmod] "unique" and "key" in nested lists
> 
> 
> > I'm not entirely sure, but RFC6110 may have a bug where it defines how
> @nma:key and @nma:unique are processed. It relies on preceding-sibling
> axis to enforce the uniqueness constraint for those. While this may work in
> non-nested lists, it does not work for nested ones. The RFC seems to assume
> that all list entries of any list are siblings, but this may not be the case.
> >
> > According to YANG (1 and 1.1), the second list entry of 'interface' list
> violates both key and unique constraints. I don't think
> 
> IMO the uniqueness constraint is only applied to entries of the same list
> instance, i.e. siblings in XPath terms. So I think your example violates neither
> "key" nor "unique" constraint.

That is what I thought too, but then I re-read the related sections and got confused. I'm not the only one, since I only stumbled upon this after I got asked this very question (global vs inside parent scope) by someone else - and couldn't answer it.

Perhaps "list entry" is not defined well enough for this corner case (though nested lists don't seem uncommon)?

Jernej

> > Also, while searching the archives for similar discussion, I stumbled upon
> one that discusses "unique" in nested lists [5]. It seems that there was WG
> consensus that "unique" schema node identifiers cannot target nodes in a
> nested list, yet I've found no text in either RFCs to enforce this. Why so?
> 
> Right, and in fact I used this feature in one of the ancient versions of ietf-
> routing. Back then I proposed to essentially use the definition from 6110 for
> dealing with such cases, but this was not accepted.
> 
> Lada
> 
> >