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