Hi -
On 5/1/2019 12:46 PM, Mikael Abrahamsson wrote:
....
Where is the text that tells the server implementor whether to throw an
error when client commits non-zero bits, or to just throw the bits away
and store the value in the canonical format?
Such text would be an inappropriate constraint the server's
internal representation. We should only specify
the externally-visible behaviour: that the reported value
will be in the canonical format. Whether an implementation
preserves extraneous cruft in its internal representation is
purely an implementation decision, and not subject to standardization.
(Even for the case of simple signed integers, it depends on my internal
number representation whether normalizing +7 to 7 causes a change of
the internal representation or not.)
I think this example is not relevant to this discussion. +7 and 7
doesn't change any integer backend representation. It's the same value.
You don't know whether it does or does not affect the internal
representation used by the backend. If the backend is a textual
configuration file virtualized through netconf, the "+" might
very well be preserved in the file, even though it would disappear
in response to a query. We only know that for purposes
of the protocol's operation, the server needs to behave as though
it is in the canonical form.
Again, I have no problem with the server throwing away the bits at
commit time, I just want it to be clear from the specs that this is the
correct behaviour and what the server should do when the above text is
not true:
"The IPv6 address should have all bits that do not belong
to the prefix set to zero."
Throw an error or "fix it"?
Since the language is "should" an error seems inappropriate.
It seems it should "fix it", so we should
have text that reflects this.
False dichotomy. An implementation might actually preserve
those bits, though of course they'd never be seen again (at
least not on a netconf interface) since the netconf server
will always behave as though the value were in its canonical
form, regardless of the internal representation.
I have no idea where this text should go,
though.
I agree with the earlier sentiment that anything addressing
this really belongs in whatever further clarification of
canonicalization goes into the update.
Randy
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
