Subject: [netmod] undecided Y19 we need a better unique

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Jun 2014 10:15:47 +0200

We need to decide whether this is in scope of YANG 1.1 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         <http://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 2 Jun 2014 08:38:14 -0700

> We need to decide whether this is in scope of YANG 1.1 or not.
IMO this new feature should be rejected because there is already
a work-around with must-stmt (as shown in the solution).
In order to maintain YANG 1.0 compatibility, there would be
2 forms of the unique-stmt to support in YANG.

> /js

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 03 Jun 2014 08:31:50 +0200 (CEST)

> a work-around with must-stmt (as shown in the solution).

Two observations:

1)  The work-around is incomprehensible, even to someone who
    understands XPath.

2)  The work-around is O(N^2) whereas the proposed solution runs
    in O(N).

> 2 forms of the unique-stmt to support in YANG.

Yes, I agree this is unfortunate.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 03 Jun 2014 14:02:21 +0200

> We need to decide whether this is in scope of YANG 1.1 or not.

I think this should be rejected because the problem doesn't exist. RFC 6110 (sec. 12.16 together with 12.8) presents IMO a reasonable XPath interpretation that works with sublists, too:

http://tools.ietf.org/html/rfc6110#section-12.16

Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jun 2014 21:19:14 +0200

> We need to decide whether this is in scope of YANG 1.1 or not.

Interim proposal:

  Proposal: Reject this request for a new feature but clarify the
  semantics of unique in RFC 6020bis (might require to open a separate
  clarification issue). A new and more powerful unique seems more like
  a YANG 2.0 work item than a YANG 1.1 work item. The consensus on
  this was rough (MB prefers to have this issue opened).

If you disagree, please speak up by June 18th.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 12 Jun 2014 10:12:28 +0200

>   this was rough (MB prefers to have this issue opened).

In fact, XSD unique is more restricted than the solution proposed in Y19. Essentially, the XPath expression in xs:field is limited to the subtree of the element where the uniqueness constraint appears. It is quite logical - speaking about uniqueness of list entries in terms of values outside the list seems a little weird.

It does make sense in the cited example from the ietf-routing module ("connected-rib" list) because of the leafref that "binds" the outside stuff to each list entry. However, such cases are IMO hard to define and not so common to warrant redesigning the "unique" statement - a "must" statement with an appropriate description should be fine.

Lada