Re: [YANG] 7.8.3 unique statement

Hi,

Andy Bierman <ietf@andybierman.com> wrote:
> Hi,
> 
> There seem to be many details left out for the unique-stmt (within a list)
> that need to be in a standard:

Ok.

>    - 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?

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.

>    - 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?

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?

>    - what is the exact behavior required for a NETCONF agent wrt/ <edit-config>
>      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?
>        unique "addr port";
>        unique "port addr";

No.

>    - Are the target nodes limited to direct definitions and expanded uses?
>      (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

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang