Re: [netmod] 6991bis: address-with-prefix-length

[Kristian Larsson <[e-mail]>]

On 2019-04-18 09:40, Ladislav Lhotka wrote:
> Juergen Schoenwaelder <[e-mail]> 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 
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 
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 
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