Re: [netmod] 6021 ipv4-prefix

[Mikael Abrahamsson <[e-mail]>]

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: [e-mail]