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] > <mailto:[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
