On Thu, 2019-04-18 at 10:09 +0200, Kristian Larsson wrote: > > On 2019-04-18 09:40, Ladislav Lhotka wrote: > > Juergen Schoenwaelder <[email protected]> writes: > > > > > On Wed, Apr 17, 2019 at 09:35:51PM +0200, Kristian Larsson wrote: > > > > I wonder though, isn't ipX-address-and-prefix-length the clearer name, > > > > or if > > > > we do want to shorten then ipX-address-and-plen. I think Martin stated > > > > the > > > > case for ipX-address-and-prefix but that is IMHO not the way this is > > > > typically perceived by people. > > > > > > > > 1.2.3.4/24 > > > > ^^^^^^^----- ipv4 address > > > > ^^^-- ipv4 prefix length > > > > > > > > now, taking the prefix-length you know that 1.2.3 is the prefix but does > > > > that mean the above is an IPv4 address and a prefix? Or is it just that > > > > you > > > > can infer the prefix from the above? It's just different ways of looking > > > > at > > > > it. My experience tells me ipX-address-and-prefix-length is the clearer > > > > way > > > > of conveying what this is. > > > > > > > > > > I guess this is somewhat subjective. The prefix length is the number > > > used to convey what the prefix is. So you are effectively defining an > > > address and the prefix that this address belongs to. ;-) > > > > Strictly speaking, what is being defined by the number is a subnet mask. > > Heh, amazing how something so binary can turn out to be so subjective ;) > This sort of turns into philosophical questions and I'm not sure we need > to straighten it all out. I'd still call the prefix-length the > prefix-length. It directly maps to the typical subnet mask > representation and as you say, they can be thought of as the same thing. > > Does this mean you prefer ipX-address-and-subnet-mask? Because I think
No. > that when someone reads that they are going to expect a value that looks > like 1.2.3.4/255.255.255.0 rather than 1.2.3.4/24, which is why I still > think ipX-address-and-prefix-length (possibly s/prefix-length/plen/) is > the better name :) > > > > > Given that we already have ip-prefix (which does as well use a prefix > > > length to convey what the prefix is), it seems ip-address-and-prefix > > > is more consistent with the existing RFC 6991 definitions. Being > > > consistent with what we have was the main reason for me to prefer > > > ip-address-and-prefix. > > > > I am not in favour of adding this type. Having ip-prefix next to > > ip-address-and-prefix is confusing. > > Confusing or not, they are NOT interchangeable and actually do different > things, which is why both are needed. There's plenty of precedence to I actually agree with you. It is a historical accident that these two different things got mixed up (and some vendors contributed to this). I would argue that - IP prefix is a set of IP addresses, and as such can be thought of as a single entity. - IP address and subnet mask/prefix are two separate things, the latter being an instruction for routing to *other* destination addresses. > > this, like postgresql has data types (cidr and inet) that map exactly to > this behaviour, i.e. both store something that looks like an IP address > and a prefix-length but one (cidr for pg) forces bits in host portion to > be set to all 0. Python ipaddress has the same with IPv4Address and > IPv4Interface. > > > > Moreover, the most natural use for > > this type would be the address specification in the "ietf-ip" module, > > but we already have two leaves there: ip and prefix-length. > > Like I said in another mail, I think it is nice if these common > datatypes become used by vendors and implementors. Many use proprietary That's fine, but we can also define a *grouping* of IP address and subnet prefix length. And if we stick to the leaves "ip" and "prefix-length", this grouping can be used in the next revision of RFC 7277. This would be my preferred solution. Lada > > models but at least using standard datatypes allows us to easily parse > the data into sensible datatypes on our end, like Python's > ipaddress.IPv4Interface. > > kll > > _______________________________________________ > 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
