Re: [netmod] 6021 ipv4-prefix

[Ladislav Lhotka <[e-mail]>]

"Rob Wilton (rwilton)" <[e-mail]> writes:

>> -----Original Message-----
>> From: netmod <[e-mail]> On Behalf Of Ladislav Lhotka
>> Sent: 02 May 2019 13:39
>> To: Mikael Abrahamsson <[e-mail]>; Randy Presuhn
>> <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [netmod] 6021 ipv4-prefix
>> 
>> Mikael Abrahamsson <[e-mail]> 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