> On Apr 24, 2020, at 11:37, tom petch <[email protected]> wrote: > > From: Joe Clarke (jclarke) <[email protected]> > Sent: 24 April 2020 14:24 > > [Bo] You are correct, and I think this model should not exclude this cases. > I am considering of two possible approach: one way is to modify enumeration > to leaf-list, the other is that 'server' list uses both 'name' and > server-type' as key values. > What do you think? > > <tp> > I am not sure I understand. I think of the traditional approach of an int > range 0..7 with 1, 2, 4 representing the three alternatives so one digit > represents any possible combination but that is Unix and not really YANG. > I see it as attractive to have one value meaning all three (which 7 would do > above) as that is a common case but I think you are suggesting a leaf-list of > one or two or three entries which works, but is a bit clumsy. Ditto > server-type as key, would you not end up with three entries in the list for a > full function server? > > Why is leaf-list clumsy? To me that seems like the right approach here. The > chmod-like bit string seems less obvious in this case. This seems akin to > the feature leaf-list in ietf-yang-library and I can see this working where > there is a server-type-identifier typedef that is an enum of the types > currently present in the module. Then you’d like instance data like: > > <server-type>authentication</server-type> > <server-type>authorization</server-type> > <server-type>accounting</server-type> > > This is more self-describing than the bit string. I wouldn’t add server-type > as a key, though. I would think that the name alone would still work. > > <tp> > I did say it was more Unix than YANG:-) > I use 'clumsy' to mean that in order to show support for all three options, > which I suspect will be the commonest case, you have to set three objects > whereas ideally you would set just the one meaning all three. I would also > use clumsy to describe introducing a fourth option to mean all three. > At present, I cannot think of a less clumsy way in YANG. Thus, I do not see > a bit string as any more attractive.
JMC> Agreed, I don’t see the bstring as more attractive. Yes, the explicit enumeration is more verbose, but it is more self-describing. I would opt for that vs. an “all” that doesn’t tell me anything unless I read the module. Joe _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
