Subject: [netmod] unique-stmt poorly defined

From: Andy Bierman <[email-masked]>
Date: Mon, 25 Aug 2008 07:30:59 -0700

Hi,

Most of the YANG constructs are documented well enough
to implement, but not the unique-stmt.  According
to the text in 7.8.3 (what there is of it),
the following YANG is legal.  Is this the
intent of this feature?

   list foo {
     key a;

     unique "b c/d";
     unique "a c/f";
     unique "c/d c/h/j c/e b";
     unique "c/d c/bar:augleaf";  // external augment
     leaf a { type int32; }
     leaf b { type int32; }
     list c {
       key "aa bb cc";

       leaf aa { type int32; }
       leaf bb { type int32; }
       leaf cc { type int32; }
       leaf d { type int32; }

       choice e {
         leaf e { type int32; }
         case e2 {
           leaf f { type int32; }
           leaf g { type int32; }
         }
         case e3 {
           list h {
             key i;
             leaf i { type int32; }
             leaf j { type int32; }
           }
         }
       }
     }
   }

If deep keys are too complicated, then unique-stmt is
also too complicated.  Why does the key-stmt restrict
the list to child leaf identifiers, but unique-stmt
does not do the same?

The current 'rules' allow way too much unintended garbage,
and the unique-stmt is not very implementable or useful
defined this way.

Are choice and case names supposed to be included in the
descendant-node-id or not?  In my example they are left out.

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Aug 2008 22:42:59 +0200 (CEST)

> the following YANG is legal.  Is this the

In our DML we could only express uniqueness for leafs within a list
entry.  But consider this (simplified) case, where an interface has a
list of addresses:

  list interface {
     ...
     list address {
        ...
        leaf ip { type inet:ipv4address; }
     }
  }

I want to say that all values of 'ip' must be unique across all
interfaces:

  list interface {
    ...
    unique "address/ip";
    ...
  }

It will not be possible to refer to augmented nodes.  It would violate
the rule that all references can be resolved and verified within a
module.   The same is true for must expressions etc.

I agree that it is unclear how it will work with choice.  I have to
think some more about this.

> descendant-node-id or not?  In my example they are left out.

The unique argument is a list of schema node identifiers, so choice
and case names are included.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Aug 2008 17:01:46 -0700

> I want to say that all values of 'ip' must be unique across all

This doesn't seem that useful as a general mechanism.
But implementing this for list or container isn't hard.

A far more likely use-case is a unique leaf-list, and
YANG does not support that at all.

> module.   The same is true for must expressions etc.

good

> think some more about this.

yes -- specifically, what does it mean if tuple T[i] is
incomplete.  Is it compared to T[j] or not?
(Where T = { unique-leaf1, unique-leaf2, ... })

Andy