"Rob Wilton (rwilton)" <rwil...@cisco.com> writes: >> -----Original Message----- >> From: netmod <netmod-boun...@ietf.org> On Behalf Of Ladislav Lhotka >> Sent: 02 May 2019 13:39 >> To: Mikael Abrahamsson <swm...@swm.pp.se>; Randy Presuhn >> <randy_pres...@alumni.stanford.edu> >> Cc: netmod@ietf.org >> Subject: Re: [netmod] 6021 ipv4-prefix >> >> Mikael Abrahamsson <swm...@swm.pp.se> writes: >> >> > On Wed, 1 May 2019, Randy Presuhn wrote: >> > >> >> Hi - >> >> >> >> On 5/1/2019 12:46 PM, Mikael Abrahamsson wrote: >> >> .... >> >>> Where is the text that tells the server implementor whether to throw >> >>> an error when client commits non-zero bits, or to just throw the >> >>> bits away and store the value in the canonical format? >> >> >> >> Such text would be an inappropriate constraint the server's internal >> >> representation. We should only specify the externally-visible >> >> behaviour: that the reported value will be in the canonical format. >> >> Whether an implementation preserves extraneous cruft in its internal >> >> representation is purely an implementation decision, and not subject >> >> to standardization. >> > >> > I am talking about what goes on the wire. If the client does an >> > edit-config with ipv6-prefix 2001:db8::1/64, should the server convert >> > this into 2001:db8::/64 or throw an error on the edit-config operation. >> > >> > Jurgen seems to say it should convert it and not throw an error, and >> > I'd like text to say that indeed, this is proper behaviour. Nobody has >> > so far been able to tell me where this text currently is, so that's >> > why I'm >> >> If we agree that a type defines the set of legal on-the-wire values (possibly >> modulo representation - JSON/XML/...), then section 4.2.2.1 in RFC 7950 says: >> >> [A leaf instance] has exactly one value of a particular type ... >> >> So why should a server throw an error if this is satisfied? > > I don't think that there is text for a derived type that defines a canonical > representation that: > (i) The server must internally treat the data as if it were in the canonical > form > (ii) If the data is returned then it must be in the canonical form.
The text is in subsection 9.1, which really should have been outside sec. 9 (Built-In Types), and applicable to derived types as well. But anyway, Mikael wrote about the case when the client sends a value (specifically, belonging to the ipv6-prefix type) that is NOT in the canonical format. Lada > > We should fix this in YANG 1.2 so this is clearer, but YANG 1.2 isn't going > to be here for a while. I don't think that we can do this as an erratum, but > perhaps the 6991bis could, for each type state that the it is handled > equivalently to RFC 7950 section 9.1. Or would that just end up being noise? > > Thanks, > Rob > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
