Re: [yang-doctors] usage of mandatory node in an optional choice

[Christian Hopps <[e-mail]>]

Martin Bjorklund <[e-mail]> writes:
> Andy Bierman <[e-mail]> wrote:
>> Hi,
>>
>> I am working on a bug in our server, and I noticed the NACM rule choice
>> is a bit odd -- why is leaf path within implied case "path" a mandatory
>> node?
>> Why does this node have mandatory=true and none of the other leafs have
>> that?
...
>> Is this 'path' leaf really mandatory, given that the choice is optional?
>> Perhaps this is future-proofing -- making sure if the case is augmented
>> that the path node is still provided?  (If so, then why not do all
>> short-case
>> definitions this way?)
>
> Future-proofing is an interesting angle.  Maybe we should use *more*
> mandatory true in cases (!) like this...?

So I recently used a choice, and wondered why the "case" name values were not
included explicitly in the tree and instead the case choice was simply implied
by one of it's leaf nodes being present from underneath the case. It struck me
as an overly clever optimization. This seems to bear that feeling out.

If one has a choice with case nodes that are non-mandatory, it would
seem that yang would allow augments to these cases to exclusively select those
cases and it might seem that these augments are backward compatible
when in fact they are not:

  module foo;
  choice X {
    case A {
      leaf a {
        type boolean;
      }
    }
    case B {
      leaf b {
        type boolean;
      }
    }
  }

  module bar;
  augment /foo:X/foo:B/ {
    leaf bb {
      type string;
    }
  }

Now a client that only implements module foo might receive:

    <bar:bb>extra-info</bar:bb>

and have no idea that case B of choice X had been chosen.

So for choices to allow for augmenting with backward compatibility each case must
have at least one mandatory leaf in it. To my earlier point, this wouldn't have
been required if the case name itself had been included in the returned tree.

Thanks,
Chris.