Re: [netmod] 6021 ipv4-prefix

[Mikael Abrahamsson <[e-mail]>]

On Tue, 30 Apr 2019, Randy Presuhn wrote:

> Hi -
>
> On 4/30/2019 1:46 AM, Mikael Abrahamsson wrote:
> ....
>> Is it generally ok that the canonical value potentially represents a
>> different bit field/value than what the client sent?
> ....
>
> The *value* represented is the same.  The sequences of bytes used
> to represent that value may be different.  Some information sent

No. 2001:db8::/64 and 2001:db8::1/64 isn't the same *value*. These are not 
the same bits set.

> by the client may be extraneous to the *value*.  Consider the case
> of currency values entered into some application.  A robust application
> won't care whether I enter $1,234,567.89 or 1234567.89 and if it
> subsequently chooses to display it as "1.234.567,89 USD" I can't
> complain that the value is different, even though several bytes of
> my input have clearly been discarded.

That's a completely different example. In your example the value is the 
same, in mine (ipv6-prefix) it isn't.

> This situation is hardly unique to netconf. I recall coding for such 
> situations forty years ago.  It has been a fact of life throughout the 
> history of ASN.1 and especially BER. It will continue to be a 
> consideration at least as long as folks feel the need to support "human 
> readable" representations on input.  Frankly, I was surprised that 
> anyone was surprised by this.

I have no problem understanding the canonicalization of IPv6 address, 
because the underlying value doesn't change by canonicalizating it. This 
is not the case with canonicalizating IPv6-prefix, where the resulting 128 
bit field *changes* when you canonicalize it.

-- 
Mikael Abrahamsson    email: [e-mail]