> -----Original Message-----
> From: netmod <[email protected]> On Behalf Of Ladislav Lhotka
> Sent: 02 May 2019 13:39
> To: Mikael Abrahamsson <[email protected]>; Randy Presuhn
> <[email protected]>
> Cc: [email protected]
> Subject: Re: [netmod] 6021 ipv4-prefix
>
> Mikael Abrahamsson <[email protected]> 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.
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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
