On Wed, May 01, 2019 at 03:12:47PM +0200, Mikael Abrahamsson wrote: > > I am fine with c), but I am also saying I disagree with your view that this > this behaviour has been specified "since the beginning". This might have > been obvious to you from the beginning, but it's not wrotten down properly > (at least I haven't seen text that makes me clearly understand the expected > behaviour). I think the text specifying what "canonical format is" referring > to "same *value*" is wrong. +17 and 17 is the same integer, 192.168.0.1/24 > and 192.168.0.0/24 are not the same *value*. It's misleading to refer to the > canonical form having the *same* *value* when we're throwing away > information. >
The basic disconnect here may be that for me the prefix is the value while for you the value is the prefix plus the unused bits. > If you write 2001:db8:0:1 as 2001:db8::1 then you're compressing the text > form without throwing away actual information. It's the *same value* buth > *different text representation*. 2001:db8::/64 and 2001:db8::1/64 is *not > the same value*. With your definition of 'value' it is not the same, with my definition of 'value' it is the same. For me, the value space of the ipv6-prefix type is the set of all possible ipv6-prefixes. And with this, 2001:db8::/64 and 2001:db8::1/64 are two different textual representations that resolve to the same prefix, i.e., the same value in the value space. I would go even further and make the following distinction between - textual representations of values of a type - the value space of a type - internal representations of values of a type I think we have this discussion because you likely map the textual representations of a prefix into an internal representation that can capture details that are (in my model) not relevant for the value space itself. (Even for the case of simple signed integers, it depends on my internal number representation whether normalizing +7 to 7 causes a change of the internal representation or not.) Once we add support to YANG for binary encodings, we will get additional complexity since we will map the value space to multiple 'external' representations and for the same type (=value space), there may be differences how 'external' representations map to the value space. A binary representation of an IPv6 address may have a 1:1 mapping to the value space while our textual representation already has a n:1 relationship. Or we go into the direction to require that all 'external' representations must only have 1:1 relationships, i.e., only textual representations in canonical format will be legal. We will see... /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
