Subject: [YANG] 7.8.3 unique statement

From: Andy Bierman <[email-masked]>
Date: Thu, 10 Jan 2008 04:29:46 -0800

Hi,

There seem to be many details left out for the unique-stmt (within a list)
that need to be in a standard:

   - what if not all the leafs listed in the unique-stmt are mandatory?
       - is the unique-stmt ignored?
       - Is NULL-value treated as one of the unique values?
       - what if some missing leafs have defaults (ensuring they will not be unique)?
   - where are the detailed specifications of the canonical formats
     for each YANG datatype (especially bits, anyxml, string) so that
     every implementation will come up with the same answer when evaluating
     uniqueness?
   - what is the exact behavior required for a NETCONF agent wrt/ <edit-config>
     processing and unique-stmt enforcement?
   - Is there any significance to the order of node identifiers?
       unique "addr port";
       unique "port addr";
   - Are the target nodes limited to direct definitions and expanded uses?
     (I.e., unique clauses that include leafs expanded from augment not allowed)

Andy

_______________________________________________
YANG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/yang

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Jan 2008 16:15:34 +0100 (CET)

Hi,

> that need to be in a standard:

Ok.

>        - Is NULL-value treated as one of the unique values?

One use case is that you have a single optional leaf in your unique
stmt.   That means that if the leaf exists, it's value has to be
unique.

Another case is that you have multiple optional leafs, and the
combination must be unique.  For example, the combination of 'name'
and 'address' in a list of persons is unique.  If you have to persons
with the same name, but no address, that would violate the uniqueness.

So, the set of existing leafs must be unique within all list entries
(if the set is non-empty).

We'll have to try to find the right wording.

>        - what if some missing leafs have defaults (ensuring they will not be unique)?

I think we should say that the leaf MUST NOT have a default.

>      every implementation will come up with the same answer when evaluating

Do we need a specification of a canonical format for this?

Do we need a specification of a canonical format also in order to
handle edit-config delete?

>      processing and unique-stmt enforcement?

It is not checked during edit-config specifically.  The text says that
the unique constraints have to be met in a valid configuration.  So
you might have temporary violations of these constraints in the
candidate e.g.

>    - Is there any significance to the order of node identifiers?

No.

>      (I.e., unique clauses that include leafs expanded from augment not allowed)

Yes.  This follows from the general rule that each definition must be
completely defined within itself.

One more thing that we have talked about adding, is to allow 'unique'
in an augment.  For example:

   augment /interface {
      unique "ifName";
      leaf ifName { ... }
      ...
   }

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Jan 2008 08:24:18 -0800

> (if the set is non-empty).

Whether a leaf is mandatory or optional is separate from the unique statement.

So the fully specified tuple must be present, and be unique [a b c]
If optional 'b' is missing [a c] then the agent ignores that entry
when enforcing the uniqueness property. (?!?)

> I think we should say that the leaf MUST NOT have a default.

no, what if the leaf is from a 'uses' expansion?
It is also OK to apply the default once.

> Do we need a specification of a canonical format for this?

yes.
For UTF-8 and float* there are references, but empty, bits, anyxml,
instance-identifier, keyref, and even numbers (17 or +17) need
canonical representations in order to compare entries.

> handle edit-config delete?

that is a side benefit (this is new NETCONF data modeling turf
that has never been properly addressed)

> you might have temporary violations of these constraints in the

good point  (it is edit-config only if the target is <running/>)

> completely defined within itself.

good

> in an augment.  For example:

I would rather not add this feature until the requirements for "augments"
are better understood.

<tangent>
One augments concern: what does it mean to declare conformance to a module?
If module FOO-MIB includes X and Y, but the vendor also has module
MY-FOO-MIB that adds a mandatory Z, does that vendor really conform to FOO-MIB?
A manager that only knows about FOO-MIB and not MY-FOO-MIB will not work,
so IMO the agent MUST NOT advertise that it supports FOO-MIB.
</tangent>

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 11 Jan 2008 17:44:10 +0100 (CET)

> when enforcing the uniqueness property. (?!?)

Yes.

> no, what if the leaf is from a 'uses' expansion?

I don't understand.

> It is also OK to apply the default once.

So you would allow one instance with the default, and the rest has to
have values set?

Ok.

> so IMO the agent MUST NOT advertise that it supports FOO-MIB.

But that won't work.  If I impplement FOO-MIB, how do I know that
there is some other module somewhere that augments it?  I think we
have to restrict the augment to not augment with any mandatory nodes.

This is be similar to the rules for versioning - you are not allowed
to add mandatory nodes in a new revision of the module.  And the
reason in both these cases is the same - to make sure that clients
that uses the old revision (or not using the module with the augment)
still work.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Jan 2008 09:03:14 -0800

>> no, what if the leaf is from a 'uses' expansion?

If the leaf with the default is in a grouping, then
that is because the DM writer wanted it that way,
and if the grouping is used in other places (than this example)
the default is OK.

> So you would allow one instance with the default, and the rest has to

no -- the value specified by the default can be used once.
If the leaf is not provided, and its value has not been used
yet, then it is OK to apply the default and still be unique.

> have to restrict the augment to not augment with any mandatory nodes.

If the manager sees FOO-MIB in the schema-discovery or capabilities,
then it will assume this MIB can be used.  No other modules or
capabilities can override the contract that is implied by the
definitions in FOO-MIB.  Period.  So MY-FOO-MIB MUST NOT
add anything that breaks the FOO-MIB contract, if the vendor
wants to claim conformance to FOO-MIB.

> that uses the old revision (or not using the module with the augment)

Standard data models require more than a language.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 11 Jan 2008 18:13:07 +0100 (CET)

> yet, then it is OK to apply the default and still be unique.

I think that this translates to treating a leaf that has its default
the same way as a non-existing leaf (in the unique test).

> wants to claim conformance to FOO-MIB.

Exactly.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 11 Jan 2008 19:12:24 +0100

> the same way as a non-existing leaf (in the unique test).
I don't understand the difference between Martin's original proposal and Andy's. Can you give 
me an example please ? Can I create two such leafs without specifying the value i.e. using the 
default? That sounds a strange kind of unique to me.

Balazs