Re: [Softwires] Review of draft-sun-softwire-yang-02

[Qi Sun <[e-mail]>]

Hi Qin,

Thanks for your comments! 

On Mar 16, 2015, at 3:54 AM, Qin Wu <[e-mail]> 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