Hi Martin,
> -----Original Message-----
> From: Martin Björklund <mbj+i...@4668.se>
> Sent: 27 February 2021 14:47
> To: Rob Wilton (rwilton) <rwil...@cisco.com>
> Cc: j.schoenwael...@jacobs-university.de; netmod@ietf.org
> Subject: Re: [netmod] type equivalence
>
> "Rob Wilton \(rwilton\)" <rwilton=40cisco....@dmarc.ietf.org> 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?
[RW]
Yes, not if you take a literal interpretation of it.
I think that the type can be replaced, if and only if:
- it resolves to the same underlying base type, and
- the semantics remains the same (as given by the description statement), and
- the value space of the new type is the same as, or a superset of, the
replaced type.
I don't think that syntax needs to be constrained if the base type and value
space are already constrained.
Rob
>
>
> /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 <j.schoenwael...@jacobs-university.de>
> > > Cc: NetMod WG <netmod@ietf.org>
> > > Subject: RE: [netmod] type equivalence
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>
> > > > Sent: 26 February 2021 17:55
> > > > To: Rob Wilton (rwilton) <rwil...@cisco.com>
> > > > Cc: netmod@ietf.org
> > > > 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
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
