Hi Qin, Thanks for your comments!
On Mar 16, 2015, at 3:54 AM, Qin Wu <[email protected]> wrote: > Looking at the model again, the way that it is currently defined is wrong. > Here’s an updated section of the model that should achieve the above: > > | +--rw (binding-v6info) > | | +—:(ipv6addr) > | | | +--rw binding-ipv6-addr inet:ipv6-address > | | +—:(ipv6pref) > | | +--rw binding-ipv6-prefix inet:ipv6-prefix > > [Qin]: Based on the above clarification, I think binding-ipv6-addr and > binding-ipv6-prefix can not coexist at the same time, both binding-ipv6-addr > and binding-ipv6-prefix should be optional leaf or choice, right? > | +--rw (binding-v6info)? > | | +—:(ipv6addr) > | | | +--rw binding-ipv6-addr? inet:ipv6-address > | | +—:(ipv6pref) > | | +--rw binding-ipv6-prefix? inet:ipv6-prefix According to the definition of “choice” in RFC6020: http://tools.ietf.org/html/rfc6020#section-4.2.7 YANG allows the data model to segregate incompatible nodes into distinct choices using the "choice" and "case" statements. The "choice" statement contains a set of "case" statements that define sets of schema nodes that cannot appear together. Each "case" may contain multiple nodes, but each node may appear in only one "case" under a "choice". Now that we’re using choice-case structure, it guarantees that binding-ipv6-addr and binding-ipv6-prefix cannot be presented at the same time. And either binding-ipv6-addr or binding-ipv6-prefix has to be mandatory node for the complete binding item. So the question marks are not necessary. Cheers, Qi
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
