if I have the following model
devices {
device {
key id;
interfaces {
interface {
key id;
unique name;
}
}
}
}
which data is valid or invalid according to yang's key and unique specification ?
1. devices/device=1/interfaces/interface=1; name = a
2. devices/device=1/interfaces/interface=1; name = b // key violation
3. devices/device=1/interfaces/interface=2; name = a // unique violation
4. devices/device=2/interfaces/interface=1; name = a // unique violation ?
supposing I store the 'interface' objects in a relational table and mark name as unique column, I cannot have both data row 3 and 4. Is that what the spec is meaning ?
or, can I interpret the uniqueness or key constraint as , unique resource path ? If I do so, the following rows of data do not conflict because they are two different resource urls, because they belong to different devices.
devices/device=1/interfaces/interface=2; name = a
devices/device=2/interfaces/interface=2; name = a
what is the right interpretation ? globally unique vs unique within the list parent ?
The correct answer is probably: it is unclear for nested lists.
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.
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.
The same text appears in RFC6020 (YANG version 1).
If you interpret it strictly, you have no choice: you have to make all list entries have a unique name globally in order to fulfill the constraint. Note that the same would apply to list's key, due to similar wording.
It is unclear whether this was the intention though.
RFC6110, which deals with YANG based instance validation using existing XML technologies, interprets it as unique within parent and it was created by the same WG: it uses the preceding-sibling:: XPath axis to enforce the constraint, which does not pick up device/id=2 interface entries inside device/id=1, since device/id=1/interfaces/interface instances and device/id=2/interfaces/interface instances are not siblings in an XML document.
Note that RFCs are not immune to bugs.