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:
On 2019-04-18 13:12, Juergen Schoenwaelder wrote:
On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote:
On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:
On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
+17.4 is not an integer, so this is an error (not because of the + but
because of the . followed by additional digits). +17 is I think a
valid
integer value but the + will be dropped in the canonical
representation.
Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of
the
prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
rounded
if an integer input is expected?
The non-prefix bits are irrelevant for the prefix and the canonical
format has the non-prefix bits all set to zero. I understand that you
prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
consider this as valid input that can be safely interpreted to mean
2001:db8::0/64.
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.";
) that the host bits
should be zero, i.e. no strict requirement.
There is no strict requirement of what? Accepting the data? Throwing an
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?
Or does 6021+6991 say such a value MAY be treated as valid input? And if
it does accept it, it must then store or at least always return it in
the canonical format?
kll
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
