On Fri, Apr 26, 2019 at 05:07:52PM +0200, Kristian Larsson wrote:
>
> 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?
>
I have added text along these lines in my sources (goes behind the
definition of the canonical format):
The definition of ipv6-prefix does not require that bits,
which are not part of the prefix, are set to zero. However,
implementations have to return values in canonical format,
which requires non-prefix bits to be set to zero. This means
that 2001:db8::1/64 must be accepted as a valid value but it
will be converted into the canonical format 2001:db8::/64.
I have added similar text to the definition of ipv4-prefix. I hope
that text like this clarifies the situation inline in the type
definition.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
