> -----Original Message-----
> From: Juergen Schoenwaelder <[email protected]>
> Sent: 29 April 2019 11:35
> 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 10:19:01AM +0000, Rob Wilton (rwilton) wrote:
> >
> > 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.
> >
>
> We have the same with +7 and 7 - if you configure an integer to be +7 you get
> the value 7 back. The alternative would be to generally disallow any types
> that
> accept multiple representations in YANG. This would then be a YANG next issue
> to bring up. In YANG 1 and 1.1, we do support "liberal inputs". (And yes, I
> know
> that some of this is also encoding specific, the hidden can or worms is indeed
> bigger. But I like to have this discussion scoped to the RFC 6991bis effort.)
I think that there is a difference between a canonical representation for base
types known to YANG, vs a defined canonical representation in a typedef's
description that requires additional typedef specific code to behave correctly
under various scenarios (e.g. server input, when comparing instance values).
I do agree that a clarification is better than the ambiguity that we have now.
But I'm not convinced that allowing ipv4-prefix values in the non-canonical
format is necessarily the right thing to do. If we were defining these as a
new type today then would we make the same choice of typedef definition?
Or is a significant part of your proposal/reasoning to ensure backwards
compatibility with what we have today?
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
