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.)

/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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to