On Fri, 2019-04-26 at 00:07 +0200, Kristian Larsson wrote: > > On 2019-04-25 23:51, Juergen Schoenwaelder wrote: > > On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote: > > > > > > On 2019-04-18 13:12, Juergen Schoenwaelder wrote: > > > > On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote: > > > > > On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote: > > > > > > On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote: > > > > > > +17.4 is not an integer, so this is an error (not because of the + > > > > > > but > > > > > > because of the . followed by additional digits). +17 is I think a > > > > > > valid > > > > > > integer value but the + will be dropped in the canonical > > > > > > representation. > > > > > > > > > > Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion > > > > > of the > > > > > prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be > > > > > rounded > > > > > if an integer input is expected? > > > > > > > > The non-prefix bits are irrelevant for the prefix and the canonical > > > > format has the non-prefix bits all set to zero. I understand that you > > > > prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991 > > > > consider this as valid input that can be safely interpreted to mean > > > > 2001:db8::0/64. > > > > > > Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax > > > error, is that implementation incorrect? > > > > > > > I think so. The types do not require that non-prefix bits are zero > > when a value is received. However, a server must report the canonical > > value, in this case 2001:db8::/64. > > Cisco NSO treats 2001:db8::1/64 as a syntax error for a leaf of type > ip-prefix (or ip6-prefix).
It is a server backend job to take care about this, the YANG type can stay more liberal. Similar differences in implementations are rather typical. Lada > > It would be interesting to hear Martins opinion on this. > > Kind regards, > Kristian. > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
