Re: [netmod] type equivalence

[Juergen Schoenwaelder <[e-mail]>]

Thanks Martin,

so you are saying that

  int8 { range "1..10"; }

is indeed different from

  uint8 { range "1..10"; }

and

  int32 { range "1..10"; }

The use of the word "syntax" in the text you quote may be a left-over
from SMIv2 times, it does not really seem to be aligned with how the
term 'syntax' is used elsewhere in RFC 7950. Anyway, if the agreement
back then was that you can't change base types (regardless of type
restrictions), it would have been nice if the text would say this more
clearly.

/js

On Mon, Feb 22, 2021 at 10:49:38AM +0100, Martin Björklund wrote:
> Hi,
> 
> Section 11 of RFC 7950 says:
> 
>    o  A "type" statement may be replaced with another "type" statement
>       that does not change the syntax or semantics of the type.  For
>       example, an inline type definition may be replaced with a typedef,
>       but an int8 type cannot be replaced by an int16, since the syntax
>       would change.
> 
> If we're just considering XML, then the syntax or encoding wouldn't
> change if we went from
> 
>   type int64 { range "2..4"; }
> 
> to
> 
>   type string { pattern "2|3|4"; }
> 
> or
> 
>   type enumeration {
>     enum 2;
>     enum 3;
>     enum 4;
>   }
> 
> or
> 
>   type union {
>     type uint8 { range "2"; }
>     type string { pattern "3"; }
>     type enumeration { enum 4; }
>   }
> 
> 
> But I don't think this is reasonable, and not the intention.  I think
> that changing the base built-in type always should be considered
> non-backwards compatible (which the quoted text above seems to imply).
> 
> 
> /martin
> 
> 
> 
> 
> Juergen Schoenwaelder <[e-mail]> wrote:
> > On Fri, Feb 19, 2021 at 10:32:34PM +0100, Carsten Bormann wrote:
> > > 
> > > 
> > > > On 2021-02-19, at 19:18, Juergen Schoenwaelder <[e-mail]> wrote:
> > > > 
> > > > I think the CBOR encoding picks different tags depending on the
> > > > signedness of the base type and this is why things are not that simple
> > > > anymore.
> > > 
> > > (This is not the CBOR encoding, but the COMI encoding of keys in URIs.)
> > 
> > OK. The CBOR document indeed says:
> > 
> > 6.1.  The unsigned integer Types
> > 
> >    Leafs of type uint8, uint16, uint32 and uint64 MUST be encoded using
> >    a CBOR unsigned integer data item (major type 0).
> > 
> > 6.2.  The integer Types
> > 
> >    Leafs of type int8, int16, int32 and int64 MUST be encoded using
> >    either CBOR unsigned integer (major type 0) or CBOR negative integer
> >    (major type 1), depending on the actual value.
> > 
> > This means the type 'int8 { range 0..10; }' leads to the same
> > encodings as the type 'uint8 { range 0..10; }'.
> > 
> > > > For the XML and JSON encodings, all definitions lead to the
> > > > same on-the-wire representation, hence the difference is more an
> > > > implementation detail. I have no clue what the gnmi people do. The
> > > > more diverse encodings we add, the more complex things get.
> > > 
> > > Well, if the equivalence expectation that I was trying to describe actually is ingrained, then whoever designs an encoding (COMI for its URI encoding included) needs to respect it.  That would be important to know.
> > > 
> > 
> > Exactly. I think we never defined this. And of course, this can get
> > even more fun if you consider string based encodings. The type
> > 
> >    type string { pattern "1|2|3|4"; }
> > 
> > yields the same _XML encoded_ value space as
> > 
> >    type int32 { range "1..4"; }
> > 
> > but as far as I recall the JSON/CBOR encodings will treat these two
> > differently. So yes, ideally the YANG language would have clear rules
> > what YANG's type equivalences are.
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> > 
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod

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