Re: [netmod] 6021 ipv4-prefix

[tom petch <[e-mail]>]

----- Original Message -----
From: "Juergen Schoenwaelder" <[e-mail]>
Sent: Wednesday, May 01, 2019 12:17 PM

> On Wed, May 01, 2019 at 10:55:38AM +0200, Mikael Abrahamsson wrote:
> >
> > 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.
>
> I personally do take the standpoint that irrelevant bits do not matter
> for the value of a prefix, i.e., 192.168.0.1/24 and 192.168.0.0/24 are
> two different representations for the same prefix. You seem to take
> the standpoint that 192.168.0.1/24 and 192.168.0.0/24 are different
> prefixes since bits that are irrelevant do differ.
>
> Apparently there are different views that people have concerning
> prefixes. I think I have seen the following three alternatives:
>
> a) non-prefix bits that are set to one are illegal in a prefix
> b) non-prefix bits are irrelevant but they need to be preserved
> c) non-prefix bits are irrelevant, ignore them and the canonical
>    representation has non-prefix bits set to zero
>
> The RFC 6991 definitions do c). If there is consensus that c) is
> wrong, we need to deprecate the definitions and create new ones after
> finding consensus on either b) or a).

And I think that c) is the correct answer (and would be for those not
involved in netmod but who have experience of the IETF - did I hear 'be
liberal in what you accept'?)

I have worked with systems that made every effort to find a reason not
to accept something that had been input, and I have worked with systems
that bend over backwards to accept something a bit flaky; different
developers have different cultures but I have always found the culture
of the IETF to be very clear on this point.  Mac, Linux and Windows have
different cultures.

There is a caveat and it is that the context must be clear.  Randy cited
' ... 1234567.89 and if it
subsequently chooses to display it as "1.234.567,89 USD" '
Well, where he is, may be, but not here where it could be

1.234.567,89 Euro
1,234,567.89 Euro
123456789 Yen
or ...
depending on the locale.

Going back to
192.168.0.1/24
then the meaning is clear as long as it is unambiguous that it is a
prefix and not more; as has been commented on (a lot of messages ago),
this could be a compound object, specifying
address+ mask
address + prefix + prefix length
etc
so it matters that the context is clear, both for the object instance
and for the organisation doing the specification.

Tom Petch

> System/kernel interfaces seem to show different behaviours. My Linux
> box seems to do a), my MacOS box seems to do c). The system/kernel
> interfaces likely all do the same if all non-prefix bits are zero,
> i.e., when the system receives data in the canonical format.
>
> Option b) seems to be the most expensive to implement (your server may
> have to clear non-prefix bits before pushing the prefix into the
> kernel and it needs to map data received from the kernel back to a
> prefix that has unused bits preserved in the datastore). Hence, for me
> the choice is between a) and c) and given that we have c) already
> defined for years, my first preference is to just keep things as they
> are.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod