Re: [netmod] Y09 introduce optional keys

[Ladislav Lhotka <[e-mail]>]

Hi Peyman,

I think you are mixing up “choice” as a schema node and the “union” type. In your example there is no amiguity at all.

Lada
 
On 17 Sep 2014, at 10:25, Peyman Owladi -X (powladi - Ensoft Ltd at Cisco) <[e-mail]> wrote:

> Hi Lada,
> 
> I had posted an example previously (which I suggested in one of the calls should be added as a note for Y09) -- reproduced here. In this case a "choice" doesn't solve the problem, as there are a set of overlapping identifiers which are actually used as the key.
> 
> ======
> A list entry may have a key which is a union; i.e. it is indexed by a single value which is one of multiple types. However, a YANG union is not always sufficient to model a choice between a set of types.
> 
> Take the following case for example:
> 
> choice maintenance-domain-identifier {
>  leaf host { type inet:host; }
>  leaf id   { type hex-string; }
>  leaf name { type string; }
> }
> 
> These strings can be overlapping, so this cannot be represented as a union.
> ======
> 
> There was a discussion of other solutions which involved more controversial extensions to the language (Y53, rejected) -- but it can be solved with Y09 by making each leaf an optional key.
> 
> Thanks,
> Peyman
> 
>> -----Original Message-----
>> From: netmod [mailto:[e-mail]] On Behalf Of Acee Lindem
>> (acee)
>> Sent: 17 September 2014 15:07
>> To: Ladislav Lhotka
>> Cc: [e-mail]
>> Subject: Re: [netmod] Y09 introduce optional keys
>> 
>> Hi Lada,
>> This might be just what we need - I¹ll discuss with the model authors.
>> The
>> other alternative is to allow all three metrics and use the most specific
>> specification. In any case, it appears that we are not dependent on
>> optional keys.
>> Thanks,
>> Acee
>> 
>> On 9/17/14, 9:49 AM, "Ladislav Lhotka" <[e-mail]> wrote:
>> 
>>> 
>>> On 16 Sep 2014, at 15:44, Acee Lindem (acee) <[e-mail]> wrote:
>>> 
>>>> Hi,
>>>> In the ISIS model, we are looking for a construct where an ISIS
>>>> interface attribute applies to level-1, level-2, or both. If it applies
>>>> to both, that is the only metric that is specified. If you specify
>>>> different metrics for level-1 and level-2 both can be specified. The
>>>> snipers below are what we have been discussing. However, it is not
>>>> really correct. Since if you specify a metric for ³all-levels², you
>>>> shouldn¹t specify anything else in the list. The suggestion was that an
>>>> optional key could handle this. The alternative would be to have a
>>>> ³metric², ³level-1-metric², and ³level-2-metric².
>>> 
>>> It seems a solution can be to use choice. It would allow to specify
>>> either one parameter to be used by both (all) levels, or a list of
>>> level-specific parameters, but not both. Something like
>>> 
>>> choice metric {
>>> leaf metric { Š }
>>> list level-metric {
>>>   key level;
>>>   leaf level { Š }
>>>   leaf metric { Š }
>>> }
>>> }
>>> 
>>> Would it make sense?
>>> 
>>> Lada
>>> 
>>> 
>>>> 
>>>> grouping interface-level-options {
>>>>    leaf level {
>>>>      type enumeration {
>>>>        enum "level-1" {
>>>>          description
>>>>            "ISIS level 1";
>>>>        }
>>>>        enum "level-2" {
>>>>          description
>>>>            "ISIS level-2";
>>>>        }
>>>>        enum "level-all" {
>>>>          description
>>>>            "All ISIS levels";
>>>>        }
>>>>   }
>>>>   default "level-all";
>>>>      description
>>>>        "Specify ISIS level for the interface command.";
>>>>    }
>>>>    description
>>>>      "ISIS interface level option.²;
>>>> }
>>>> 
>>>> list isis-metric {
>>>>       key "level";
>>>>        description "ISIS interface metric";
>>>>         leaf value {
>>>>                type uint32;
>>>>                description "ISIS metric value";
>>>>         }
>>>>         uses interface-level-options;
>>>> }
>>>> 
>>>> 
>>>> Thanks,
>>>> Acee
>>>> Andy Bierman <andy at yumaworks.com
>>>>> wrote:
>>>>> On Thu, Sep 4, 2014 at 12:21 PM, Martin Bjorklund <mbj at
>>>> tail-f.com
>>>>> wrote:
>>>>> 
>>>>>> David Reid <reid at
>>>> snmp.com
>>>>> wrote:
>>>>>>>> Here is a proposal for how to introduce optional keys.
>>>>>>> 
>>>>>>> Adding optional keys seems like a pretty major new feature for
>>>>>>> a .1 release. Most of the other issues are fixes or
>>>> clarifications.
>>>>>>> Is the benefit worth the cost?
>>>>>> 
>>>>>> I don't think the cost is that high.  With YANG 1.0, people are
>>>> forced
>>>>>> to use awkward workarounds, and/or vendor-specific extensions to
>>>>>> support a use case that seems to be natural in many circumstances.
>>>>>> Thus, I think it is better to support this natively.
>> (Incidentally,
>>>>>> just today I got a question from someone involved in the broadband
>>>>>> forum work why YANG doesn't support optional keys).
>>>>>> 
>>>>>> 
>>>>> 
>>>>> I think the implementation impact is significant, but the feature
>>>> could be
>>>>> useful.
>>>>> The protocol complexity increase is worse that the compiler.
>>>>> What about adding optional keys to an existing entry?
>>>>> IMO this cannot be supported with either RESTCONF or NETCONF.
>>>>> The request will be seen by the server as a create, merge, or
>> replace
>>>> on
>>>>> a new resource instance.
>>>> 
>>>> Right, and I think this is ok.  In general it would be nice with a
>>>> 'rename' operation in the protocols, but that is a different issue.
>>>> 
>>>> 
>>>> /martin
>>>> 
>>>> 
>>>> _______________________________________________
>>>> netmod mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> 
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>> 
>>> 
>>> 
>>> 
>> 
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C