"Rob Wilton (rwilton)" <[email protected]> writes: > Forking the thread title to avoid further polluting the original issue, and > because these comments really apply to YANG.Next. > >> -----Original Message----- >> From: Juergen Schoenwaelder <[email protected]> >> Sent: 29 April 2019 18:26 >> To: Rob Wilton (rwilton) <[email protected]> >> Cc: Ladislav Lhotka <[email protected]>; NETMOD WG <[email protected]> >> Subject: Re: [netmod] 6021 ipv4-prefix >> >> 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. > > Yes, OK. > > But this really means that YANG has two sorts of typedefs: > > (i) A regular typedef which is just an alias for a base type, perhaps with > some additional refinements that can all be handled automatically (e.g. > pattern statements, etc). In this scenario, I think that a compiler can > ignore the description, and process the typedef automatically. > (ii) An enhanced typedef that has additional semantics embedded into the > description statement that requires custom implementation of the typedef. > > Being able to distinguish these two cases in a programmatic way seems > useful to me, but perhaps it is just unnecessary noise.
YANG assumes "powerful" descriptions in general. An option would be to find a way for specifying the canonical format in a machine-readable form. > > For the second case, I do wonder whether this is much closer to adding new > concrete type to the language, just in a slightly backdoor way. There have > been discussions about adding binary representations for some of these types > (e.g IPv4 address, IPv6 address ,etc). Perhaps that would be easier if they > were somewhat closer to base types than derived types, and maybe this class > of type definitions shouldn't be using typedef at all. > >> >> > 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. > > I wasn't suggesting that we lose uniqueness of list keys, but instead > don't allow typedefs to define their own canonical format. I.e. that > would always require IPv6 addresses to be provided in the canonical > form. However, the benefits of this are probably marginal given that This just shifts the burden to the client side, with pretty much the same issues. I think that the client should be allowed to send IPv6 addresses in any form permitted by RFC 4291. Lada > a robust server would want to check that the type is in the canonical > form anyway, and hence the server still has to write very similar > canonicalization code regardless. > > >> >> 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. > > I've raised https://github.com/netmod-wg/yang-next/issues/83 to clarify the > expected YANG behaviour here, and perhaps to also consider whether an extra > statement would be beneficial. > > Thanks, > Rob > > >> >> /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/> -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
