On Wed, 1 May 2019, Juergen Schoenwaelder wrote:
I personally do take the standpoint that irrelevant bits do not matter for the value of a prefix, i.e., 192.168.0.1/24 and 192.168.0.0/24 are two different representations for the same prefix. You seem to take the standpoint that 192.168.0.1/24 and 192.168.0.0/24 are different prefixes since bits that are irrelevant do differ.
No, I am saying this is underspecified or actually wrongly specified in the current documents + proposed text regarding what canonical format is and isn't, and how the server and clients handle this.
I am fine with the current proposed text to specify this for ipv6-prefix, but I am also pointing out that I think when YANG 1.2 is specced, the definition for "canonical format" needs more/changed text.
Apparently there are different views that people have concerning prefixes. I think I have seen the following three alternatives: a) non-prefix bits that are set to one are illegal in a prefix b) non-prefix bits are irrelevant but they need to be preserved c) non-prefix bits are irrelevant, ignore them and the canonical representation has non-prefix bits set to zero The RFC 6991 definitions do c). If there is consensus that c) is wrong, we need to deprecate the definitions and create new ones after finding consensus on either b) or a).
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.
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*.
I am fine with us continuing with c) above, I have long stopped arguing for anything else. What I am though saying is that I want https://tools.ietf.org/html/rfc7950#section-9.1 (or elsewhere) to have better text on this matter when the documents are revved next time.
-- Mikael Abrahamsson email: [email protected] _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
