----- Original Message ----- From: "Kristian Larsson" <[email protected]> Sent: Thursday, April 25, 2019 11:07 PM
> 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. Kristian No way can I approach being Martin but .. this topic has been active on the 6man list and to some extent on the main IETF list with one very active participant arguing that because widely-used implementations allow something that the RFC does not (making use of the 64 zero bits of fe80::/10) then the RFC is wrong and should be changed. Happily this seems to be a minority view but, like a hydra, the thread keeps coming back to life in another form see e.g. Re: encoding link ID in link-local addrs Re: about violation of standards Globally Unique Link Local Addresses mailing list activity who should try to explain who shouuld update even Re: [Technical Errata Reported] RFC7421 (5699) In fact almost any post to 6man in the past 10 days (of which there are many) Tom Petch > Kind regards, > Kristian. > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
