On 19/04/18 20:22, Anil Vishnoi wrote: > All of this results in better overall user experience, I think, but that > is just my opinion. > > Yes, these are good suggestion and OFP project can take these into > account for future enhancement, but why they can't use the existing > thing in the way it is? > Let me drill down to very simple question (to get an answer that i can > understand at my level). > > https://git.opendaylight.org/gerrit/#/c/71083/3/openflowjava/openflow-protocol-spi/src/main/yang/openflow-switch-connection-config.yang > > > > Why do i need to change ipv4-address to ipv4-addresss-no-zone here in > my yang model? Given that both of these are very valid derive type > defined in ietf-types.
The answer to this question is modeling exercise. Does a zone make sense in this context? It is not a matter of 'it could be supported', anything not defying laws of Physics can be supported. The question is: does it make sense? can you show an example when it would be immediately useful? > As far as i understood, MDSAL can't implement it in a way I want to use > (non-breakable), because of language limitation or some other reasons. > So there are two options > > (1) We merge the change and move all the project to these API (given > that they cannot be used in the way defined in yang model) > (2) Do not implement support for ipv4-adderss-no-zone (as it's creating > confusion), and let user use the ipv4-address (which can support no-zone > and zone ip addresses) (3) we change how generated DataObject.equals() works. Bye, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
