Unable to determine actual type of VTN flow match/action via RESTCONF.

Some VTN flow data models are defined using YANG choice statement.

• layer-4 flow match (vtn-layer4-match)
• flow action (vtn-action)

Branch name of YANG choice does not appear in XML/JSON serialized data.
So REST client cannot determine actual type of layer-4 flow match and flow action if it obtains those data via RESTCONF.

For example, a data-flow-action list which contains a vtn-pop-vlan-action will be converted to JSON notation like this:

"data-flow-action": [

{ "order": 0 }

],

REST client cannot determine the actual type of above action because no type information appears.

VTN YANG models defined by choice statement should be modified as follows:

• Every vtn-action case should contain an inner container which indicates the actual type.
  For example, vtn-pop-vlan-action should be defined as follows.

case vtn-pop-vlan-action-case {
container vtn-pop-vlan-action {}
}

The name of the container always appears in XML/JSON serialized data.
So a data-flow-action list which contains a vtn-pop-vlan-action will be converted to JSON as follows.

"data-flow-action": [
{
"order": 0,
"vtn-pop-vlan-action": {}
}
],

• The name of inner field in vtn-layer4-match case should have a prefix which indicates the actual type.
  For example, vtn-icmp-match-fields should be defined as follows.

grouping vtn-icmp-match-fields {
leaf icmp-type

{ type uint8; }
leaf icmp-code { type uint8; }

}

A data-flow-match which contains a vtn-icmp-match will be converted to JSON as follows.

"data-flow-match": {
"icmp-code": 0,
"icmp-type": 8,
"vtn-ether-match":

{ "ether-type": 2048, }

,
"vtn-inet-match":

{ "protocol": 1 }

},

REST client can determine ICMP match conditions by "icmp-" prefix in field name.