On 2019-04-26 13:28, Ladislav Lhotka wrote:
On Fri, 2019-04-26 at 12:56 +0200, Kristian Larsson wrote:
On 2019-04-26 09:39, Ladislav Lhotka wrote:
On Thu, 2019-04-25 at 23:51 +0200, Juergen Schoenwaelder wrote:
On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
error, is that implementation incorrect?
I think so. The types do not require that non-prefix bits are zero
when a value is received. However, a server must report the canonical
value, in this case 2001:db8::/64.
Agreed. The description only says (and only for ipv6-prefix
I think it says it for ipv4-prefix too:
...
The canonical format of an IPv4 prefix has all bits of
the IPv4 address set to zero that are not part of the
IPv4 prefix.";
This defines the canonical format, and Juergen explained its role earlier in
this thread.
Ah yes, I see now, you're right.
error? Ambiguity of what you are referencing makes it impossible for me
to parse your sentence. Please elaborate.
I'm having trouble unifying the following:
- Juergen says RFC6021 and 6991 consider 2001:db8::1/64 to be valid
input that can safely be interpreted to mean 2001:db8::/64
- NSO instead treats 2001:db8::1/64 as a syntax error
If 6021+6991 says it is valid input, then NSO must accept it, no?
I am not familiar with NSO. If it uses the the types from ietf-inet-types and
refuses to accept such input values from a NETCONF/RESTCONF client, then it
looks like a bug to me.
It does use these types so filing bug report I guess.
it does accept it, it must then store or at least always return it in
the canonical format?
RFC 7950 says in sec. 9.1 that the server MUST return values in the canonical
form and that the values are conceptually stored in the canonical form (in a
datastore).
Thanks for the reference, it helps! :)
Kind regards,
Kristian.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
