On Mon, 2019-04-29 at 14:02 +0000, Rob Wilton (rwilton) wrote: > > -----Original Message----- > > From: Juergen Schoenwaelder <[email protected]> > > Sent: 29 April 2019 14:46 > > To: Rob Wilton (rwilton) <[email protected]> > > Cc: Acee Lindem (acee) <[email protected]>; [email protected] > > Subject: Re: [netmod] 6021 ipv4-prefix > > > > On Mon, Apr 29, 2019 at 01:33:22PM +0000, Rob Wilton (rwilton) wrote: > > > But I'm not convinced that allowing ipv4-prefix values in the non- > > > canonical > > format is necessarily the right thing to do. If we were defining these as a > > new > > type today then would we make the same choice of typedef definition? > > > > > > Or is a significant part of your proposal/reasoning to ensure backwards > > compatibility with what we have today? > > > > I am trying to clarify what the existing definition says since there > > apparently > > have been different interpretations. > > Given the definition of ipv6-prefix already contains: > > " The IPv6 address should have all bits that do not belong > to the prefix set to zero." > > I think that a better solution might be to add the equivalent text to the > ipv4-prefix definition: > > " The IPv4 address should have all bits that do not belong > to the prefix set to zero."
But this still essentially permits the client to send a value with those bits set, and the server has to be prepared to handle it. If the goal is to get rid of the difference between ipv4- and ipv6-prefix, which makes sense, then I prefer to remove this sentence from ipv6-prefix. Lada > > Thanks, > Rob > > > > /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 -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
