[netmod] I-D Action: draft-ietf-netmod-yang-module-versioning-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : Updated YANG Module Revision Handling
Authors : Robert Wilton
  Reshad Rahman
  Balazs Lengyel
  Joe Clarke
  Jason Sterne
  Benoit Claise
  Kevin D'Souza
Filename: draft-ietf-netmod-yang-module-versioning-02.txt
Pages   : 40
Date: 2021-02-22

Abstract:
   This document specifies a new YANG module update procedure that can
   document when non-backwards-compatible changes have occurred during
   the evolution of a YANG module.  It extends the YANG import statement
   with an earliest revision filter to better represent inter-module
   dependencies.  It provides help and guidelines for managing the
   lifecycle of YANG modules and individual schema nodes.  It provides a
   mechanism, via the revision-label YANG extension, to specify a
   revision identifier for YANG modules.  This document updates RFC
   7950, RFC 8407 and RFC 8525.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-module-versioning-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : Common YANG Data Types
Author  : Juergen Schoenwaelder
Filename: draft-ietf-netmod-rfc6991-bis-05.txt
Pages   : 41
Date: 2021-02-22

Abstract:
   This document introduces a collection of common data types to be used
   with the YANG data modeling language.  This document obsoletes RFC
   6991.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6991-bis-05
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-core-comi-11 shepherd review

[Carsten Bormann]

Please note an interesting discussion over at netmod.

Archived-At: 
 and 
up.

It seems we a converging to a conclusion that means that the table at the top 
of page 14 in draft-ietf-core-comi-11.txt [1] is not wrong (it would make 
certain updates of a YANG module a non-backwards compatible change in the way 
we build URIs from that).

[1]: https://tools.ietf.org/html/draft-ietf-core-comi-11#page-14

That said, maybe we still want to look at why uint and int coding are so 
(unnecessarily?) different in their URL encodings.

Grüße, Carsten



> On 2021-02-04, at 05:47, Carsten Bormann  wrote:
> 
> In my shepherd review of draft-ietf-core-comi-11, I have found a few points 
> that probably need some WG action before we can submit this draft to IESG.
> (I also have submitted a PR addressing some nits, 
> https://github.com/core-wg/comi/pull/1 .)
> 
> Specifically:
> 
> # Major
> 
> *** 5: This whole section is rather disappointing.  What does this
>really do except for pointing at RFC 7959?  Is there any
>recommendation in how to work around the race condition?  The
>recommendation to use indefinite length is not solving any problem
>(does not work except in very fortuitous cases).
> 
> *** 6.2.2 How does the pagination work, then?
>This SHOULD is not actionable.
> 
> *** 7: This creates confusion between 4.01 and 4.03
> 
> # Minor
> 
> *** 2.2: While it is not clear whether there will be a SID 0, the text
> seems to imply that this would be encoded in the empty string.
> Should it rather specify a single "A”?
> 
> *** Appendix A:  Updated to reference RFC 8949 (see PR).
> Do we need a new module version after this edit?
> 
> 
> Grüße, Carsten
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] type equivalence

[Carsten Bormann]

On 2021-02-22, at 15:17, Juergen Schoenwaelder 
 wrote:
> 
> I guess considering the built-in types as incompatible is the most
> robust approach. If we agree that RFC 7950 tried to say this, we could
> file an errata and propose clearer language.

Right.  And we can keep the COMI key-to-URL mapping as is, as this 
clarification is necessary for its correct functioning.

Grüße, Carsten

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] type equivalence

[Juergen Schoenwaelder]

On Mon, Feb 22, 2021 at 02:55:57PM +0100, Carsten Bormann wrote:
> On 2021-02-22, at 14:53, Juergen Schoenwaelder 
>  wrote:
> > 
> > Yes, "base type" is the wrong term, I think we talk about what RFC
> > 7950 calls "build-in types”.
> 
> OK, so rephrasing my question:
> 
> Are all built-in types incompatible in the sense that moving from one to the 
> other is NBC, or are there clusters where moving within is innocuous?
> 

I do not think we ever had the notion of "clusters" (or something like
the universal unlimited INTEGER in ASN.1, a common root of all fixed
precision integer types).

Martin and Lada seem to say that all built-in types are incompatible.
Lada made the point that range restrictions can be expanded and hence
the differences of the size or the signedness of the underlying
built-in type may eventually matter.

Of course, if we go down this route, then encodings may take advantage
of this. I have no clue what code generators do, if they indeed map

type int32 { range "0..10"; }

to a 32-bit signed number (to be prepared that someone may enlarge the
range) or whether they go for more space efficient representations
(and then versioning issues may arise or you live with implicit
integer conversions if your programming language does them).

I guess considering the built-in types as incompatible is the most
robust approach. If we agree that RFC 7950 tried to say this, we could
file an errata and propose clearer language.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] type equivalence

[Carsten Bormann]

On 2021-02-22, at 14:53, Juergen Schoenwaelder 
 wrote:
> 
> Yes, "base type" is the wrong term, I think we talk about what RFC
> 7950 calls "build-in types”.

OK, so rephrasing my question:

Are all built-in types incompatible in the sense that moving from one to the 
other is NBC, or are there clusters where moving within is innocuous?

Grüße, Carsten



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] type equivalence

[Juergen Schoenwaelder]

On Mon, Feb 22, 2021 at 11:47:05AM +0100, Carsten Bormann wrote:
> 
> 
> > On 2021-02-22, at 11:13, Martin Björklund  wrote:
> > 
> > Juergen Schoenwaelder  wrote:
> >> Thanks Martin,
> >> 
> >> so you are saying that
> >> 
> >>  int8 { range "1..10"; }
> >> 
> >> is indeed different from
> >> 
> >>  uint8 { range "1..10"; }
> >> 
> >> and
> >> 
> >>  int32 { range "1..10"; }
> > 
> > Yes.
> 
> Oh.  People often choose uint8 etc. with an intention to set a range.
> I don’t think they know that they are setting themselves up for NBC if that 
> range needs to be extended later.
> So I would have expected that there is a common base type these are all 
> derived from.
> 
> RFC 7950 does not use "base type" as an absolute term; it only can be used 
> relative to “derived type”.
> I don’t know which of the built-in types are “absolute base types” in the 
> sense you would need it to define the rule.
>

Yes, "base type" is the wrong term, I think we talk about what RFC
7950 calls "build-in types".

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] type equivalence

[Carsten Bormann]

On 2021-02-22, at 10:24, Juergen Schoenwaelder 
 wrote:
> 
> 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.

We certainly called this out as expected collateral damage when we developed 
YANG-CBOR.

So my “deductive rule of type equivalence” is not faithfully respected by 
YANG-CBOR.  We did see a need to bow to it for unions, though.

> So yes, ideally the YANG language would have clear rules
> what YANG's type equivalences are.

For a value of “ideal” that is closer to “fundamentally necessary” :-)

Grüße, Carsten

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] type equivalence

[Carsten Bormann]

> On 2021-02-22, at 11:13, Martin Björklund  wrote:
> 
> Juergen Schoenwaelder  wrote:
>> Thanks Martin,
>> 
>> so you are saying that
>> 
>>  int8 { range "1..10"; }
>> 
>> is indeed different from
>> 
>>  uint8 { range "1..10"; }
>> 
>> and
>> 
>>  int32 { range "1..10"; }
> 
> Yes.

Oh.  People often choose uint8 etc. with an intention to set a range.
I don’t think they know that they are setting themselves up for NBC if that 
range needs to be extended later.
So I would have expected that there is a common base type these are all derived 
from.

RFC 7950 does not use "base type" as an absolute term; it only can be used 
relative to “derived type”.
I don’t know which of the built-in types are “absolute base types” in the sense 
you would need it to define the rule.

Grüße, Carsten

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] type equivalence

[Ladislav Lhotka]

On 22. 02. 21 11:11, Juergen Schoenwaelder wrote:
> On Mon, Feb 22, 2021 at 11:00:36AM +0100, Ladislav Lhotka wrote:
> 
>> But I thought that Jürgen's question was directed to the definition of
>> backward compatibility in the semver context.
> 
> No, the background is not semver here, it is "can we harmonize N
> different existing definition of "0..100" to one. And it seems the
> answer is "no", at least not in a backwards compatible way if people
> picked different base types.

+1

Lada

> 
> /js
> 

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] type equivalence

[Martin Björklund]

Juergen Schoenwaelder  wrote:
> Thanks Martin,
> 
> so you are saying that
> 
>   int8 { range "1..10"; }
> 
> is indeed different from
> 
>   uint8 { range "1..10"; }
> 
> and
> 
>   int32 { range "1..10"; }

Yes.

> The use of the word "syntax" in the text you quote may be a left-over
> from SMIv2 times

[That's what I thought as well, but I couldn't find it in the SMIv2
RFCs.  Perhaps it was from some sming text?]

> , 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.

Agreed.


/martin



> 
> /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  wrote:
> > > On Fri, Feb 19, 2021 at 10:32:34PM +0100, Carsten Bormann wrote:
> > > > 
> > > > 
> > > > > On 2021-02-19, at 19:18, Juergen Schoenwaelder 
> > > > >  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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   +49 421 200 3103 
> > > 
> > > ___
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] type equivalence

[Juergen Schoenwaelder]

On Mon, Feb 22, 2021 at 11:00:36AM +0100, Ladislav Lhotka wrote:

> But I thought that Jürgen's question was directed to the definition of
> backward compatibility in the semver context.

No, the background is not semver here, it is "can we harmonize N
different existing definition of "0..100" to one. And it seems the
answer is "no", at least not in a backwards compatible way if people
picked different base types.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] type equivalence

[Juergen Schoenwaelder]

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  wrote:
> > On Fri, Feb 19, 2021 at 10:32:34PM +0100, Carsten Bormann wrote:
> > > 
> > > 
> > > > On 2021-02-19, at 19:18, Juergen Schoenwaelder 
> > > >  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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] type equivalence

[Ladislav Lhotka]

On 22. 02. 21 10:49, 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).

Agreed. Another problem related to sec. 11 is that it permits to update
a module so that the range specification is extended, which may then
expose the incompatibility of e.g. uint8 and int8.

But I thought that Jürgen's question was directed to the definition of
backward compatibility in the semver context.

Lada

> 
> 
> /martin
> 
> 
> 
> 
> Juergen Schoenwaelder  wrote:
>> On Fri, Feb 19, 2021 at 10:32:34PM +0100, Carsten Bormann wrote:
>>>
>>>
 On 2021-02-19, at 19:18, Juergen Schoenwaelder 
  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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103 
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] type equivalence

[Martin Björklund]

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  wrote:
> On Fri, Feb 19, 2021 at 10:32:34PM +0100, Carsten Bormann wrote:
> > 
> > 
> > > On 2021-02-19, at 19:18, Juergen Schoenwaelder 
> > >  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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] type equivalence

[Juergen Schoenwaelder]

On Fri, Feb 19, 2021 at 10:32:34PM +0100, Carsten Bormann wrote:
> 
> 
> > On 2021-02-19, at 19:18, Juergen Schoenwaelder 
> >  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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod