On Tue, Apr 30, 2019 at 10:46:34AM +0200, Mikael Abrahamsson wrote: > On Tue, 30 Apr 2019, Juergen Schoenwaelder wrote: > > > I think we go in circles in this thread and I will stop explaining > > things again and again. I suggest people look at the next revision > > and if anything remains unclear, people can send concrete edit > > proposals. > > You don't have to explain it. Let me try in a different way. > > https://tools.ietf.org/html/rfc7950#section-9.1 > > "For most types, there is a single canonical representation of the > type's values." > > Is it generally ok that the canonical value potentially represents a > different bit field/value than what the client sent?
Yes. I explained that the canonicalization of IPv6 addresses is much more involved than clearing some unused bits in an IPv6 prefix. > If it is (and that's fine by me), I think this should be made more clear in > the next rev of the YANG specification. I feel the whole "canonical/lexical > format" concept is underspecified, for instance in the case of ipv6-prefix. There is text defining the canonical format since day one. I proposed an addition that hopefully makes this even clearer. > In the text you suggested before that fixes ipv6-prefix. Do we have more > types where this needs to be fixed? We are not 'fixing' anything. The canonical format is nothing new. The text aims at explaining things better. Yes, there are many more types that have a canonical representation. Read the other email messages in this thread or simply search for 'canonical' in the type definitions. I think the descriptions are actually all quite clear (but then I am biased of course). /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
