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]
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
