Re: [netmod] type equivalence

[Martin Björklund <[e-mail]>]

"Rob Wilton \(rwilton\)" <rwilton=[e-mail]> 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 <[e-mail]>
> > Cc: NetMod WG <[e-mail]>
> > Subject: RE: [netmod] type equivalence
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder <[e-mail]>
> > > Sent: 26 February 2021 17:55
> > > To: Rob Wilton (rwilton) <[e-mail]>
> > > Cc: [e-mail]
> > > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod