Re: [netmod] 6021 ipv4-prefix

[Kristian Larsson <[e-mail]>]

On 2019-04-26 09:39, Ladislav Lhotka wrote:
> On Thu, 2019-04-25 at 23:51 +0200, Juergen Schoenwaelder wrote:
>> On Thu, Apr 25, 2019 at 11:20:57PM +0200, Kristian Larsson wrote:
>>>
>>> On 2019-04-18 13:12, Juergen Schoenwaelder wrote:
>>>> On Thu, Apr 18, 2019 at 12:53:22PM +0200, Mikael Abrahamsson wrote:
>>>>> On Thu, 18 Apr 2019, Juergen Schoenwaelder wrote:
>>>>>> On Thu, Apr 18, 2019 at 11:43:05AM +0200, Mikael Abrahamsson wrote:
>>>>>> +17.4 is not an integer, so this is an error (not because of the + but
>>>>>> because of the . followed by additional digits). +17 is I think a
>>>>>> valid
>>>>>> integer value but the + will be dropped in the canonical
>>>>>> representation.
>>>>>
>>>>> Yes, but 2001:db8::1/64 isn't valid prefix (because the host portion of
>>>>> the
>>>>> prefix isn't 0) so why should it be "rounded" when 17.4 shouldn't be
>>>>> rounded
>>>>> if an integer input is expected?
>>>>
>>>> The non-prefix bits are irrelevant for the prefix and the canonical
>>>> format has the non-prefix bits all set to zero. I understand that you
>>>> prefer 2001:db8::1/64 to be an error but RFC 6021 and RFC 6991
>>>> consider this as valid input that can be safely interpreted to mean
>>>> 2001:db8::0/64.
>>>
>>> Vice versa, if an implementation does treat 2001:db8::1/64 as a syntax
>>> error, is that implementation incorrect?
>>>
>>
>> I think so. The types do not require that non-prefix bits are zero
>> when a value is received. However, a server must report the canonical
>> value, in this case 2001:db8::/64.
> 
> Agreed. The description only says (and only for ipv6-prefix

I think it says it for ipv4-prefix too:

   ...
   The canonical format of an IPv4 prefix has all bits of
   the IPv4 address set to zero that are not part of the
   IPv4 prefix.";


> ) that the host bits
> should be zero, i.e. no strict requirement.
There is no strict requirement of what? Accepting the data? Throwing an 
error? Ambiguity of what you are referencing makes it impossible for me 
to parse your sentence. Please elaborate.

I'm having trouble unifying the following:
- Juergen says RFC6021 and 6991 consider 2001:db8::1/64 to be valid 
input that can safely be interpreted to mean 2001:db8::/64
- NSO instead treats 2001:db8::1/64 as a syntax error

If 6021+6991 says it is valid input, then NSO must accept it, no?

Or does 6021+6991 say such a value MAY be treated as valid input? And if 
it does accept it, it must then store or at least always return it in 
the canonical format?

    kll