On 2019-04-26 13:18, Juergen Schoenwaelder wrote:
On Fri, Apr 26, 2019 at 12:56:57PM +0200, Kristian Larsson wrote:
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?
I do not find anything in 6021+6991 that says 2001:db8::1/64 is
illegal input. If it were illegal, we would not need the definition of
the canonical format that is in 6021+6991. Apparently text could have
been more explicit but if you connect the bits and pieces, I think the
conclusion must be that 2001:db8::1/64 is allowed input, i.e., you do
not have to clear the bits that are irrelevant but the server will do
this since it has to return the value in canonical format.
Thanks for your time in answering this Juergen, much appreciated.
I think the canonical representation is quite clear as is the part that
the server must return data (and conceptually store) in canonical
format. What is much less clear is the allowed input formats which then
includes 2001:db8::1/64. I think it could be worthwhile to explicitly
state this as it is a bit surprising. Unlike say the uintX types, there
is no "lexical representation" section for ip-prefix (I presume because
they are not basetypes and so the lexical presentation follows the base,
string in this case + the pattern) that explains things in any detail.
Do you think we could add some clarifications, perhaps to the
description of the type about this? Or could we even add a lexical
representation section with examples? Or just an examples section?
Kind regards,
Kristian.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
