"Acee Lindem (acee)" <[email protected]> writes:
> Hi Juergen,
>
> On 4/26/19, 11:36 AM, "netmod on behalf of Juergen Schoenwaelder"
> <[email protected] on behalf of [email protected]>
> wrote:
>
> 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.
This just says how the canonical format works, and this is already
defined in RFC 7950. I know this particular type is a hot topic right
now, but there are other places where the canonical format may come into
play. I think that YANG readers should just understand what it is about.
Perhaps it would suffice to add a reference to the corresponding RFC
7950 section:
OLD
The canonical format of an IPv[46] prefix has all bits of ...
NEW
The canonical format (see sec. 9.1 of RFC 7950) of an IPv[46] prefix
has all bits of ...
>
> 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.
>
> I must admit that I think this is the worst possible
> outcome. Independent of the original intent, at a high level it is
> just not a good idea to accept the non-canonical prefix format and
> return the canonical format.
But this is how the canonical format is supposed to work! There are
other types with multiple lexical formats, and the canonical format is
basically just the Postel principle applied to the server: Be liberal in
what you accept, and conservative in what you send.
The expected server behaviour in this case can be a problem only if the
ipv[46]-prefix is (mis)used as IP address & network prefix length combo.
Lada
>
> Thanks,
> Acee
>
>
>
> /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
>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
