Re: [netmod] 6021 ipv4-prefix

[Juergen Schoenwaelder <[e-mail]>]

On Mon, Apr 29, 2019 at 05:08:41PM +0000, Rob Wilton (rwilton) wrote:
> 
> If YANG allows a typedef to refine the canonical definition of a
> base type, then I think that the YANG RFC should be explicit on this
> (e.g. in YANG Next).  Particularly, because this requires a server
> implementation to read/understand the description associated with a
> leaf/typedef in case they have to add specific canonicalization code
> to implement the leaf/typedef.

Description statements in general are expected to be read and
understood and implemented where necessary. But I now see that the
fact that this section 9.1 is under section 9 which is titled built-in
types is causing the confusion. This is, indeed, unfortunate.
 
> I'm not sure that we have really got a simple solution for either clients or servers:
>  1) Clients may use non canonical format on configuration input
>  2) But clients must still use canonical format for xpath expressions
>  3) Clients must also handle canonical format being returned on any get requests.
>  4) Servers must perform normalization of any type to a canonical format, as defined in the type/typedef/leaf description.

Exactly. Note that clients only send xpath for filtering (if they want
to filter via xpath). What is more important is that module authors
can predict the format of values when they write when or must
expressions. And as Lada points out, having predictable key values
also is kind of desirable.

The reality is that there are many different ways to write an IPv6
address and the idea was to accept them on input but to subsequently
work with the normalized canonical representation. And this is in
ietf-yang-types and ietf-inet-types since day one. But yes, the
text in section 9.1 seems to be misplaced.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>