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

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

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

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-b

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

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 wou

Re: [netmod] type equivalence

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 mappin

Re: [netmod] type equivalence

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 i

Re: [netmod] type equivalence

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 cl

Re: [netmod] type equivalence

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

Re: [netmod] I-D Action: draft-ietf-netmod-yang-semver-02.txt

This new version: * adds text on how semver gaps are handled (issue #61) * makes semver as a revision-label mandatory for IETF modules (issue #45) * adds text for how IANA modules are to be handled with respect to adding semver revision-labels (issue #59). Joe On 2/21/21 12:06, internet-dra...@i

Re: [netmod] type equivalence

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 i

Re: [netmod] type equivalence

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

Re: [netmod] type equivalence

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 w

Re: [netmod] type equivalence

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 SMIv

Re: [netmod] type equivalence

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 o

Re: [netmod] type equivalence

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 '

Re: [netmod] type equivalence

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 t

Re: [netmod] type equivalence

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 int

Re: [netmod] type equivalence

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