----- Original Message ----- From: "Juergen Schoenwaelder" <[email protected]> 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
