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: [email protected]
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
