On Thu, Apr 19, 2018 at 10:57 AM, Robert Varga <[email protected]> wrote: > > That's because you are talking more about openflow should use no-zone, > > because that's the right way to do for openflow, which i agree with. But > > my question here is about the derive types, if ipv4-address-no-zone and > > ipv4-address are two derive types and user are free to use any of these > > derive type. Currently openflowplugin is using ipv4-address, so why they > > have to change their yang model to use no-zone. > > https://git.opendaylight.org/gerrit/#/c/71083/3/extension/ > openflowjava-extension-nicira/src/main/yang/nicira-action.yang > > <https://git.opendaylight.org/gerrit/#/c/71083/3/extension/ > openflowjava-extension-nicira/src/main/yang/nicira-action.yang> > > > > [#]https://git.opendaylight.org/gerrit/#/c/71083/ > > <https://git.opendaylight.org/gerrit/#/c/71083/> > > This a proposed patch, a starting point -- and merging this will break > OFP downstreams. It just happens to do all that is needed on the OFP > side to completely verify. > > The end result is of that is two-fold: > > 1) user cannot specify a zone by mistake, because having a zone there is > no longer valid -- any attempt to do that will fail-fast. > > 2) OFP can rely on that data to be validated to not contain a zone and > being a plain IP addres -- and hence can remove code stripping it > > 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. 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) > Regards, > Robert > > -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
