Re: [netmod] 6021 ipv4-prefix

[Randy Presuhn <[e-mail]>]

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