Hi Ian,
If you are talking about the tree model, I think it should just simply like
the following if only using the 'if-feature',
+--rw br-instances
+--rw binding {binding}?
| +--rw br-instance* [id]
| +--rw ...
|
+--rw algorithm {algorithm}?
+--rw algo-instance* [id]
+--rw ...
BR,
Linhui
2018-01-12 20:48 GMT+08:00 Ian Farrer <[email protected]>:
> Hi Linhui,
>
> Could you provide a proposed structure for your suggestion of using only
> ‘if-feature’?
>
> Thanks,
> Ian
>
> On 12. Jan 2018, at 13:14, Linhui Sun <[email protected]> wrote:
>
>
> 2018-01-12 20:04 GMT+08:00 Ian Farrer <[email protected]>:
>
>> Hi Linhui,
>>
>> > 4) The usage of choice statement is not very clear, why do we need to
>>> use the 'case' and 'feature' statements together? It seems that we only
>>> need one of them.
>>>
>>> [if - Well, a CE may implement binding and/or algorithm. If it
>>> implements one, then there is no choice to be made. If it implements both,
>>> then it can only configure one type hence the choice. If it needed to
>>> implement two types for whatever reason, then there would be two instances
>>> of the model attached to different interfaces.
>>>
>> [LH]: That sounds strange, why not just restricting the CE/BR instance
>> (not the actual device) to be only one of them (i.e. binding & algorithm)?
>> In this way, only 'if-feature' is needed.
>>
>>
>> Can you provide a (high level) example of how you would structure this?
>>
> Hi Ian,
>
> This is what defined in the current model:
> choice br-type {
> case binding {
> if-feature binding;
> container binding {
> if-feature binding;
> ...
> }
> }
> case algorithm {...}
> }
>
> What if we just use the following:
> container binding {
> if-feature binding;
> ...
> }
> container algorithm {
> if-feature algorithm;
> ...
> }
>
>>
>> Thanks,
>> Ian
>>
>
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
