On 2021-03-16, at 19:44, Juergen Schoenwaelder
wrote:
>
> representation
There are several representations. Which one is meant?
Grüße, Carsten
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
After some iteration with Rob, here is a new version:
NEW'''
o A "type" statement may be replaced with another "type" statement
as long as the underlying built-in type and the representation
and semantics of the type do not change (other than allowed by
other rules in this
On Fri, Feb 26, 2021 at 07:05:32PM +, Rob Wilton (rwilton) wrote:
>
>
> E.g., I'm wondering, would your proposed new definition allow us to change
> from the IETF to IEEE MAC address definition? The underlying type is the
> same (String), and arguably the semantics of both types is the
Hi Martin,
> -Original Message-
> From: Martin Björklund
> Sent: 27 February 2021 14:47
> To: Rob Wilton (rwilton)
> Cc: j.schoenwael...@jacobs-university.de; netmod@ietf.org
> Subject: Re: [netmod] type equivalence
>
> "Rob Wilton \(rwilton\)" wro
> And in the final step change leaf foo from using tempInt to use biggerInt.
>
> Rob
>
>
> > -Original Message-
> > From: Rob Wilton (rwilton)
> > Sent: 26 February 2021 19:06
> > To: Juergen Schoenwaelder
> > Cc: NetMod WG
> > Subjec
{
type int8 { range "0..200"; };
}
And in the final step change leaf foo from using tempInt to use biggerInt.
Rob
> -Original Message-
> From: Rob Wilton (rwilton)
> Sent: 26 February 2021 19:06
> To: Juergen Schoenwaelder
> Cc: NetMod WG
> Subject: RE: [n
> -Original Message-
> From: Juergen Schoenwaelder
> Sent: 26 February 2021 17:55
> To: Rob Wilton (rwilton)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] type equivalence
>
> On Fri, Feb 26, 2021 at 03:27:39PM +, Rob Wilton (rwilton) wrote:
> >
On Fri, Feb 26, 2021 at 03:27:39PM +, Rob Wilton (rwilton) wrote:
>
> Sure, but if we are going to submit an errata for this definition, we want to
> ensure that updated definition is clear in all axes, not only the specific
> issue that was originally raised.
>
This is where the IETF
From: Andy Bierman
Sent: 26 February 2021 14:57
To: Juergen Schoenwaelder ; Rob Wilton
(rwilton) ; netmod@ietf.org
Subject: Re: [netmod] type equivalence
On Fri, Feb 26, 2021 at 3:45 AM Juergen Schoenwaelder
mailto:j.schoenwael...@jacobs-university.de>>
wrote:
On Fri, Feb 26, 2021
> -Original Message-
> From: Martin Björklund
> Sent: 26 February 2021 16:37
> To: Rob Wilton (rwilton)
> Cc: a...@yumaworks.com; netmod@ietf.org
> Subject: Re: [netmod] type equivalence
>
> "Rob Wilton (rwilton)" wrote:
> >
> >
>
> > Cc: Rob Wilton (rwilton) ; netmod@ietf.org
> > > Subject: Re: [netmod] type equivalence
> > >
> > > Andy Bierman wrote:
> > > > On Fri, Feb 26, 2021 at 7:06 AM Martin Björklund
> > > wrote:
> > > >
> > > > > &qu
"Rob Wilton (rwilton)" wrote:
>
>
> > -Original Message-
> > From: Martin Björklund
> > Sent: 26 February 2021 16:30
> > To: a...@yumaworks.com
> > Cc: Rob Wilton (rwilton) ; netmod@ietf.org
> > Subject: Re: [netmod] type equivalenc
> -Original Message-
> From: Martin Björklund
> Sent: 26 February 2021 16:30
> To: a...@yumaworks.com
> Cc: Rob Wilton (rwilton) ; netmod@ietf.org
> Subject: Re: [netmod] type equivalence
>
> Andy Bierman wrote:
> > On Fri, Feb 26, 2021 at 7:0
elder
> > > > Sent: 24 February 2021 20:39
> > > > To: netmod@ietf.org
> > > > Subject: Re: [netmod] type equivalence
> > > >
> > > > Here is an attempt to come up with better wording. If people agree on
> > > > a new wordin
On Fri, Feb 26, 2021 at 7:06 AM Martin Björklund wrote:
> "Rob Wilton \(rwilton\)" wrote:
> >
> >
> > > -Original Message-
> > > From: netmod On Behalf Of Juergen
> Schoenwaelder
> > > Sent: 24 February 2021 20:39
> > >
> -Original Message-
> From: Juergen Schoenwaelder
> Sent: 26 February 2021 14:28
> To: Rob Wilton (rwilton)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] type equivalence
>
> On Fri, Feb 26, 2021 at 12:21:26PM +, Rob Wilton (rwilton) wrote:
> >
&
"Rob Wilton \(rwilton\)" wrote:
>
>
> > -Original Message-
> > From: netmod On Behalf Of Juergen Schoenwaelder
> > Sent: 24 February 2021 20:39
> > To: netmod@ietf.org
> > Subject: Re: [netmod] type equivalence
> >
> > Here is
On Fri, Feb 26, 2021 at 3:45 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> On Fri, Feb 26, 2021 at 11:31:58AM +, Rob Wilton (rwilton) wrote:
> >
> > I also note that draft-ietf-netmod-yang-module-versioning-02 states:
> >
> >This document updates [RFC7950]
On Fri, Feb 26, 2021 at 12:21:26PM +, Rob Wilton (rwilton) wrote:
>
>
> > -Original Message-
> > From: netmod On Behalf Of Juergen Schoenwaelder
> > Sent: 24 February 2021 20:39
> > To: netmod@ietf.org
> > Subject: Re: [netmod] type equivalence
&g
> -Original Message-
> From: netmod On Behalf Of Juergen Schoenwaelder
> Sent: 24 February 2021 20:39
> To: netmod@ietf.org
> Subject: Re: [netmod] type equivalence
>
> Here is an attempt to come up with better wording. If people agree on
> a new wordin
On Fri, Feb 26, 2021 at 11:31:58AM +, Rob Wilton (rwilton) wrote:
>
> I also note that draft-ietf-netmod-yang-module-versioning-02 states:
>
>This document updates [RFC7950] section 11. Section 3 describes
>modifications to YANG revision handling and update rules, and
>Section 4
Hi Juergen,
> -Original Message-
> From: Juergen Schoenwaelder
> Sent: 25 February 2021 20:02
> To: Rob Wilton (rwilton)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] type equivalence
>
> On Thu, Feb 25, 2021 at 07:22:27PM +, Rob Wilton (rwilton)
On Thu, Feb 25, 2021 at 07:22:27PM +, Rob Wilton (rwilton) wrote:
>
> As an AD:
> Whether this can be done as a verified errata isn't so clear, but would
> obviously depend on the proposed text.
>
I have proposed text that tries to fix the unfortunate use of
'syntax'. Does the AD see an
> -Original Message-
> From: Juergen Schoenwaelder
> Sent: 25 February 2021 18:01
> To: Rob Wilton (rwilton)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] type equivalence
>
> On Thu, Feb 25, 2021 at 05:10:21PM +, Rob Wilton (rwilton) wrote:
>
On Thu, Feb 25, 2021 at 10:00 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> On Thu, Feb 25, 2021 at 05:10:21PM +, Rob Wilton (rwilton) wrote:
> >
> > Since the YANG module versioning draft clarifies the BC/NBC rules,
> perhaps we could add text to clarify this in
On Thu, Feb 25, 2021 at 05:10:21PM +, Rob Wilton (rwilton) wrote:
>
> Since the YANG module versioning draft clarifies the BC/NBC rules, perhaps we
> could add text to clarify this in that draft?
>
> I.e., perhaps something for section 3.1.3 of
>
> -Original Message-
> From: netmod On Behalf Of Martin Björklund
> Sent: 22 February 2021 10:14
> To: j.schoenwael...@jacobs-university.de
> Cc: netmod@ietf.org
> Subject: Re: [netmod] type equivalence
>
> Juergen Schoenwaelder wrote:
> > Thanks Mar
Here is an attempt to come up with better wording. If people agree on
a new wording, I volunteer to submit an errata.
OLD
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
From: netmod on behalf of Martin Björklund
Sent: 22 February 2021 10:13
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
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
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
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
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
> >>
>
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
> 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.
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
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
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
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
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
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
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.
>
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. 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
On 2021-02-19, at 17:55, Juergen Schoenwaelder
wrote:
>
> Hi,
>
> can I safely replace
>
>leaf foo {
> type int8 { range "0..100"; };
>}
>
> with
>
>leaf foo {
> type uint8 { range "0..100"; };
>}
>
> or with
>
>leaf foo {
> type int32 { range "0..100";
Hi,
can I safely replace
leaf foo {
type int8 { range "0..100"; };
}
with
leaf foo {
type uint8 { range "0..100"; };
}
or with
leaf foo {
type int32 { range "0..100"; };
}
or are these a non-backwards compatible changes? Note that the value
set is
45 matches
Mail list logo
