Re: [YANG] key clause issues

Balazs Lengyel wrote:
> See below
> 
> PS.:
> The reason for the existence of YANG is that it is more simple then 
> XSD." quote from Balazs
> 
> Andy Bierman wrote:
>> Hi,
>>
>> I have a few concerns with the key clause...
> ...
> 
>> Issue 2)
>>
>>   Why is the CLR about a leaf appearing more than once in the key needed?
>>   It should be up to the DM writer to decide if this makes sense or not:
>>
>>    list addr-pairs {
>>      key "addr-type src-addr addr-type dest-addr";
>>
>>      leaf addr-type { type ietf:InetAddressType; }
>>      leaf src-addr { type ietf:InetAddress; }
>>      leaf dest-addr { type ietf:InetAddress; }
>>      // ... rest of list entry
>>    }
>>
>>    Why is this illegal?
>>    It may be bad practice (according to RFC 4001), but should it be 
>> illegal?
> [BALAZS]: When the user/programmer uses this in an edit-config he might 
> think that the two add-types are two distinct pieces of data, while they 
> are actually the same.
> 

Why would they think that?
The path to the node (/addr-pairs/addr-type) is the same.
That is enough info for the manager to know they are the same object.

> Would the user actually have to provide the addr-type twice in a netconf 
> message?

no -- the key is conceptual -- not actually identifiable in
any NETCONF PDU as a key.

> How do you handle if the two provided values in a netconf request are 
> not the same?

The point of this DM design would be that the addr-pairs are
always the same addr-type so listed it twice is always redundant.
If the addr-pairs could ever be different addr types for each addr,
then a different table design would be used.

We need to give the DM writer the tools to make good decisions.
We do not need a ton of CLRs that assume the DM writer does
not know what to do.  CLRs should be used when the consensus
is that more often than not, bad things will happen without the CLR.
What bad things happen by not forbidding a key component from
appearing more than once?

> 
> 

Andy

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