Re: [netmod] 6021 ipv4-prefix

[Mikael Abrahamsson <[e-mail]>]

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]