Re: [YANG] 7.8.3 unique statement

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
>> Martin Bjorklund wrote:
>>> 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. (?!?)
> 
> Yes.
> 
>>> 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?
> 
> I don't understand.
> 

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.

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

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.

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

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.

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

Standard data models require more than a language.

> 
> 
> /martin
> 
> 

Andy

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