Sorry, but I wish to raise another question regarding changing types.
Are you allowed to change from one type to another type that 'contains' the
first type.
typedef smallInt {
type int8 { range "0..100"; };
}
typedef biggerInt {
type int8 { range "0..200"; };
}
Can I change leaf foo from:
leaf foo {
type smallInt;
}
to:
leaf foo {
type biggerInt;
}
I'm not sure that the chapter 11 rules in RFC 7950 formally allow this (either
with or without the proposed errata), but intuitively I would expected this to
be allowed by commutativity, since this change is clearly legal if you go via a
third intermediate type.
E.g., you could change leaf foo from using smallInt to a new tempInt:
typedef tempInt {
type int8 { range "0..100"; };
}
Then, as a second update, change the range in tempInt:
typedef tempInt {
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 <[email protected]>
> Cc: NetMod WG <[email protected]>
> Subject: RE: [netmod] type equivalence
>
>
>
> > -----Original Message-----
> > From: Juergen Schoenwaelder <[email protected]>
> > Sent: 26 February 2021 17:55
> > To: Rob Wilton (rwilton) <[email protected]>
> > Cc: [email protected]
> > Subject: Re: [netmod] type equivalence
> >
> > On Fri, Feb 26, 2021 at 03:27:39PM +0000, 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 shines, there is an attempt to fix a minor
> > problem and the result is N additional possible problems are put on
> > the table to be considered as well before the minor problem can be
> > fixed. My interest was the original question since I did run into it,
> > my interest is low in fixing all other possible problems that people
> > can think of.
> [RW]
>
> I'm not convinced that accurately describes the situation.
>
> If it helps to clarify, I have three specific goals here:
>
> (1) Check that the proposed corrected text doesn't contain further bugs
> that also need to be fixed. After all you cannot file an errata on an
> errata, and it doesn't look great for me if I have to request that a
> verified errata is changed to rejected because it contains further issues
> in a two sentence paragraph.
>
> (2) Workout whether the errata can be marked as verified, hold for update,
> or needs to be rejected.
>
> (3) Check that the same bug doesn't exist in other places. I agree that
> this is a tangential goal, and I have already forked this into a separate
> thread, as you had requested.
>
> I am not asking you to generically fix or define "semantics", but I really
> would like our proposed replacement text to be entirely unambiguous, and
> contain no further issues.
>
> 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 same (i.e.,
> they both represent an IEEE 802 MAC address), but the syntax of the two
> types clearly differs.
>
> Regards,
> Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
