Re: [netmod] 6021 ipv4-prefix

[Juergen Schoenwaelder <[e-mail]>]

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: [e-mail]

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>