Re: [netmod] 6021 ipv4-prefix

["Rob Wilton (rwilton)" <[e-mail]>]

> -----Original Message-----
> From: Juergen Schoenwaelder <[e-mail]>
> Sent: 29 April 2019 11:02
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: Acee Lindem (acee) <[e-mail]>; [e-mail]
> Subject: Re: [netmod] 6021 ipv4-prefix
> 
> On Mon, Apr 29, 2019 at 09:51:41AM +0000, Rob Wilton (rwilton) wrote:
> > Hi Juergen,
> >
> > > -----Original Message-----
> > > From: netmod <[e-mail]> On Behalf Of Juergen
> > > Schoenwaelder
> > > Sent: 26 April 2019 18:30
> > > To: Acee Lindem (acee) <[e-mail]>
> > > Cc: [e-mail]
> > > Subject: Re: [netmod] 6021 ipv4-prefix
> > >
> > > On Fri, Apr 26, 2019 at 04:55:02PM +0000, Acee Lindem (acee) wrote:
> > > > Hi Juergen,
> > > >
> > > > I must admit that I think this is the worst possible outcome.
> > > > Independent of the
> > > original intent, at a high level it is just not a good idea to
> > > accept the non- canonical prefix format and return the canonical format.
> > > >
> > >
> > > So you propose to deprecate the definitions and create new ones?
> > > Otherwise, I can't follow why a clarification can be the worst possible
> outcome.
> > >
> > > Note that we do have different lexical representations this in
> > > several other places. We accept +17 to mean 17 (Section 9.1 of RFC
> > > 7950.)
> >
> > This feels somewhat different.  I think that it well understood that these are
> just the same thing.  E.g. anything that parses these into a integer type will
> internally end up with the same value in both cases.
> >
> 
> For me, 10.0.0.0/8 and 10.0.0.1/8 both denote the same IPv4 prefix.

It is obvious to me that internally the router should treat these the same, i.e. in the canonical format.
It is also obvious to me that the operational value reported for this should be "10.0.0.0/8".

But it isn't obvious to me that if the input configuration contains "10.0.0.1/8" then when the client requests that configuration back again it should get "10.0.0.0/8" back rather than the value that they provided in the input configuration.

To me, that probably means that a sensible client should just use the canonical format.  Does it improve interop for the type to allow the non-canonical format on input?  That isn't obvious to me either.


> 
> > I have a related question on the fraction-digits type:
> >
> >      typedef my-decimal {
> >        type decimal64 {
> >          fraction-digits 2;
> >          range "1 .. 3.14 | 10 | 20..max";
> >        }
> >      }
> >
> > Should a server accept a value of "3.140" for my-decimal?
> >
> > What about "3.141"?  I presume that servers would generally not accept (and
> then round) this value, and except clients to round appropriately before passing
> the value in.
> 
> Please start a separate thread if you want to discuss this.

I was attempting to use it as a similar example for consistency.  I.e. one where extra data is provided and whether the input is validated strictly or loosely.

Thanks,
Rob


> 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>