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: > > > > > 2001:db8::/64 and 2001:db8::1/64 are NOT the same if you use them. > > > > Why are they not the same if you define a prefix? > > Because they're not. One of them is a valid prefix, the other one isn't.
Well, this has gone twice through WG last call and twice through IESG review plus several directorate reviews. In the canonical format, the non-prefix bits are all zero. I fail to see why this is now a problem. > > +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. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
