Hi Mikael,
On 4/18/19, 3:17 AM, "netmod on behalf of Mikael Abrahamsson"
<[email protected] on behalf of [email protected]> wrote:
On Tue, 16 Apr 2019, [email protected] wrote:
> We might need to clarify this with the libyang folk.
I see that Michal fixed the bug in libyang. Good.
There is another thing I am unsure about.
What is the netconf server supposed to do if a client tries to store
192.168.1.1/24 in ipv4-prefix ? Or 2001:db8::1/64 in ipv6-prefix?
Since the constraint on the non-masked portion of the prefix is solely in the
description, there is nothing to prevent this and I'm sure the ipv4-prefix and
ipv6-prefix types are being used incorrectly.
Thanks,
Acee
Reading the canonical format description in 6021 one might intepret that
the netconf server should just truncate the host bits and store these as
192.168.1.0/24 and 2001:db8::/64 ? This means the netconf server actually
stored something else than the client tried to commit (the resulting
uint32 and uint128 will have different information than was commited by
the netconf client).
Or should the netconf server throw an error if the client tries to commit
data that is not according to the bit pattern described in the canonical
format?
I guess I am getting confused by the "canonical format" term being used in
IPv6 for describing the ascii representation of the value, but both in
IPv4 and IPv6 it's also used to describe how the bits should be set (and
not be set) depending on prefix/mask.
Also, the IPv4 canoncical format representation doesn't describe at all
the ascii representation, so for instance 192.168.001.001 would be valid
according to 6021. I haven't seen this to be a problem in reality though,
because IPv4 addresses are typically "compressed" the same way, all the
time. If we're revving 6021, then perhaps some text about ascii
representation format should be to use the format used by the posix
function inet_ntoa() ?
--
Mikael Abrahamsson email: [email protected]
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
