> -----Original Message-----
> From: Juergen Schoenwaelder <[email protected]>
> Sent: 29 April 2019 11:02
> To: Rob Wilton (rwilton) <[email protected]>
> Cc: Acee Lindem (acee) <[email protected]>; [email protected]
> 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 <[email protected]> On Behalf Of Juergen
> > > Schoenwaelder
> > > Sent: 26 April 2019 18:30
> > > To: Acee Lindem (acee) <[email protected]>
> > > Cc: [email protected]
> > > 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
