Re: [netmod] 6021 ipv4-prefix

[Mikael Abrahamsson <[e-mail]>]

On Tue, 30 Apr 2019, Juergen Schoenwaelder wrote:

> On Tue, Apr 30, 2019 at 10:46:34AM +0200, Mikael Abrahamsson wrote:
>> On Tue, 30 Apr 2019, Juergen Schoenwaelder wrote:
>>
>>> 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.
>>
>> You don't have to explain it. Let me try in a different way.
>>
>> https://tools.ietf.org/html/rfc7950#section-9.1
>>
>> "For most types, there is a single canonical representation of the
>>    type's values."
>>
>> Is it generally ok that the canonical value potentially represents a
>> different bit field/value than what the client sent?
>
> Yes. I explained that the canonicalization of IPv6 addresses is much
> more involved than clearing some unused bits in an IPv6 prefix.

The canonicalization of IPv6 addresses doesn't change the resulting 128 
bit pattern. Canonicalization of IPv6-prefix *does* change the bit 
pattern. Also, it doesn't say in 
https://tools.ietf.org/html/rfc7950#section-9.1 whether the server should 
accept bit-fields that do not adhere to the canonical representation or 
not.

So while you seem to think I am not reading your text, it seems to me 
you're not reading what I am saying either. You're not responding to the 
points I am trying to make anyway.

https://tools.ietf.org/html/rfc7950#section-9.1

This talks about *values*. If you drop bits in IPv6-prefix, then it's not 
the same *value* anymore.

So https://tools.ietf.org/html/rfc7950#section-9.1 should be changed 
in future revisions to avoid confusion.

> We are not 'fixing' anything. The canonical format is nothing new. The
> text aims at explaining things better. Yes, there are many more types
> that have a canonical representation. Read the other email messages in
> this thread or simply search for 'canonical' in the type definitions.
>
> I think the descriptions are actually all quite clear (but then I am
> biased of course).

There are lots of implications that are *not* clear in 
https://tools.ietf.org/html/rfc7950#section-9.1.

-- 
Mikael Abrahamsson    email: [e-mail]