"Rob Wilton \(rwilton\)" <[email protected]> wrote:
> 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;
> }
Yes, this was clearly the intention.
We have these two rules:
o A "range", "length", or "pattern" statement may expand the allowed
value space.
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.
But I assume you mean that the second bullet doesn't allow an expanded
value space?
/martin
>
> 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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
