Can you please explain it a bit, i am not sure what do you mean by "inferred from anything machine-readable"?
On Wed, Apr 18, 2018 at 10:07 AM, Robert Varga <[email protected]> wrote: > Unfortunately that cannot be inferred from anything machine-readable, so > we have to make do with what we have. > > Sent from my BlackBerry - the most secure mobile device - via the Orange > Network > *From:* [email protected] > *Sent:* April 18, 2018 6:57 PM > *To:* [email protected] > *Cc:* [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected] > *Subject:* Re: Build breakage in openflowplugin due IP address NoZone > changes > > > > On Wed, Apr 18, 2018 at 9:49 AM, Robert Varga <[email protected]> wrote: > >> Hello Anil, >> >> No, support is not being removed, but Ipv4Address.equals() is defined in >> a way which returns false when compared with Ipv4AddressNoZone of the same >> value IIRC, hence things would break. >> > This is not correct behavior in my opinion, because ietf clearly says > that user "may" add zone, so the equals should not fail if two ipv4-address > (without zone) is compared. > > >> >> Yes, applications can support zones and conversion from NoZone is cheap, >> so it is a matter of preference. >> >> Sent from my BlackBerry - the most secure mobile device - via the Orange >> Network >> *From:* [email protected] >> *Sent:* April 18, 2018 6:13 PM >> *To:* [email protected] >> *Cc:* [email protected]; [email protected]; >> [email protected]; [email protected]; >> [email protected] >> *Subject:* Re: Build breakage in openflowplugin due IP address NoZone >> changes >> >> Hi Robert, >> >> Please see inline.. >> >> On Wed, Apr 18, 2018 at 1:33 AM, Robert Varga <[email protected]> wrote: >> >>> On 18/04/18 08:09, D Arunprakash wrote: >>> > Hello, >>> > >>> > The following review in mdsal might have impacted openflowplugin >>> > functionality. >>> > >>> > https://git.opendaylight.org/gerrit/#/c/70769/ >>> >>> Sorry about that. >>> >>> > https://jenkins.opendaylight.org/releng/job/openflowplugin-m >>> aven-verify-fluorine-mvn33-openjdk8/259/console >>> > >>> > >>> > >>> > org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.iet >>> f.inet.types.rev130715.Ipv4Address<Ipv4Address{_value=0.1.2.3}> >>> > but was: >>> > org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.iet >>> f.inet.types.rev130715.Ipv4AddressNoZone<Ipv4Address{_value=0.1.2.3}> >>> > >>> > is it new expectation on openflowplugin to change from Ipv4Address to >>> > Ipv4AddressNoZone ? >>> >>> There are two aspects to this. >>> >>> As an interim, the codecs from wire need to be updated to convert >>> Ipv4AddressNoZone to Ipv4Address, so that equality works as expected and >>> the breakage is recovered -- https://git.opendaylight.org/gerrit/71072 >>> does that. >>> >> This seems like regression. ietf-type (2013-07-15) supports both the >> version and this revision seems to be backward compatible. So are you >> removing the support for ipv4-address type? >> >> >>> >>> Going forward, though, I believe the openflow models need to be updated >>> to require ipv4-address-no-zone rather than ipv4-address (and same goes >>> for ip-address and ipv6-address). This really is the correct thing to do >>> -- ipv4-address is not really the IPv4 address used in OpenFlow protocol. >>> >> Yeah for flows /groups true, but that does not mean application can't >> use ipv4_address with zone. >> >> >>> >>> Regards, >>> Robert >>> >>> >> >> >> -- >> Thanks >> Anil >> > > > > -- > Thanks > Anil > -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
