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.
/js On Tue, Apr 30, 2019 at 07:24:17AM +0200, Mikael Abrahamsson wrote: > On Mon, 29 Apr 2019, Juergen Schoenwaelder wrote: > > > I believe we are not in the position to tell clients that they should or > > should not do. If I push the config value 2001:DB8::/64 (since my > > database has values stored using uppercase characters) and it comes back > > as 2001:db8::/64, then so be it; it might be convenient for me to be > > allowed to push 2001:0DB8:0:0:0:0:0:0/64 and not having to worry about > > how to produce the RFC 5952 representation in my glue code that ties > > into my database backend. Why would we say clients should not send > > values in non-canonical format? Why would we say clients have to take > > the pain to ensure everything is turned into 2001:db8::/64 (to continue > > the example) before sending values to the server? > > > > Note that the ipv6-address definition has the same canonicalization > > properties (if we consider the address portion of ipv6-prefix) and > > there is no text saying you should send 2001:db8::1 instead of > > 2001:0DB8::1. > > 2001:0DB8::1 and 2001:db8::1 represent the same thing in the end. > 2001:db8::/64 and 2001:db8::1/64 is not the same thing in the end. > > The fact that the server accepts 2001:db8::1/64 and turns it into > 2001:db8::/64 is something I believe should be explicitly stated. It's not > obvious from neither the description of what a "canonical format" is in the > YANG spec whether this also applies to dropping actual representation. > > A contrived example is if I specify a canonical format for a string that is > [a-f] and I sent it "abcdefghij" then the server just accepts this and turns > it into "abcdef"? That's basically what's happening above. A lot of people > would be astonished by this behaviour, and I think this should be more > explicit when this is happening. From what we're seeing now from different > implementations doing differently, this is not obvious. > > > I think our mission instead is to make it clear what the canonical > > format is and that servers will turn lexical representations they accept > > into canonical lexical representation. This way people can take informed > > decisions about what is appropriate for their specific clients. > > The ipv6-prefix type doesn't have a lexical definition. An integer has > lexical definition. Does this mean everything should have both just to make > sure everything is clear? And should a server disallow input that doesn't > adhere to the lexical format? > > I just want it to be 100% clear from reading about what lexical and > canonical format is what the server should and shouldn't do in each case. > > I still think there is a difference between representation of the underlying > information being changed or not. For instance, DNS domain names are case > insensitive. Turning input into lower case (canonical format) is fine, this > changes nothing operationally. Accepting client edit-config and just > removing ASCII characters can cause unexpected and baffling behavior. > > I still believe that if a client does edit-config on a DNS domain and > include for instance a "%" in the name then the server should throw an > error. So same thing with the ipv6-prefix, it needs to be defined whether > the server should accept (and zero) host bits or not. > > Do we have other types with this kind of ambiguity? > > -- > Mikael Abrahamsson email: [email protected] -- 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
