+1 Cheers, Jeff
> On Apr 18, 2019, at 6:12 AM, Lou Berger <lber...@labn.net> wrote: > > Having worked with UIs that have the behavior of accepting an > address/prefix-len and mapping it to a prefix, (i.e., network/prefix-len and > zeroing out the non-significant bits) - some users really like it as they > don't have to do the transformation from address to network, notably for odd > length prefixes, while other users hate it as the system shows/does something > different than what they entered. > > In the end the current definition is what it is. If we want something > different we can define it. I personally think an address/prefix-len would be > useful, and would leave ip-prefix as is. (again just an individual's > opinion.) > > Lou > >> On 4/18/2019 6:53 AM, 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. >> >>> +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? >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
