Re: [YANG] 7.8.3 unique statement

Martin Bjorklund wrote:
> 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).
> 

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. (?!?)

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

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

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

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.

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

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

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

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

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

good

> 
> 
> One more thing that we have talked about adding, is to allow 'unique'
> in an augment.  For example:
> 
>    augment /interface {
>       unique "ifName";
>       leaf ifName { ... }
>       ...
>    }
> 

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>

> 
> /martin
> 
> 

Andy

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