Kristian Larsson <krist...@spritelink.net> 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 would be interesting to hear Martins opinion on this.
I did some digging, and it turns out that we had this type internally before it was part if ietf-inet-types, where we did not require that all non-prefix bits were zero, but at one point (after draft-ietf-netmod-yang-types-00 back in 2008) checked in a fix: The confd:ipv4Prefix and confd:ipv6Prefix types now require that all bits that do not belong to the prefix are set to zero. This is for compatibility with the corresponding YANG types defined by the IETF NETMOD working group. You may want to see the threads: https://mailarchive.ietf.org/arch/msg/netmod/bXL0Mec_ZVVyalmK3pNHkczm6ZI https://mailarchive.ietf.org/arch/msg/netmod/3Wz5BPgxZajCZloAOjU-ycfr9Lg Specifically Juergen's proposal: Require that all bits that are not part of the prefix are set to zero (192.0.2.8/24 becomes an invalid representation of an IPv4 prefix) I can't find any discussion in the archive about allowing non-zero non-prefix bits. So I think that the original intention was to be strict in these types. I agree that the current description text needs clarification in either case. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
