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

Ladislav Lhotka <> Thu, 25 April 2019 08:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 350E61200E5 for <>; Thu, 25 Apr 2019 01:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oRMgVmgCWTQF for <>; Thu, 25 Apr 2019 01:31:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 364BC120075 for <>; Thu, 25 Apr 2019 01:31:33 -0700 (PDT)
Received: by (Postfix, from userid 109) id 81ADA1820414; Thu, 25 Apr 2019 10:31:54 +0200 (CEST)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id 4400E1820408; Thu, 25 Apr 2019 10:31:36 +0200 (CEST)
From: Ladislav Lhotka <>
To: Per Hedeland <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Mail-Followup-To: Per Hedeland <>,
Date: Thu, 25 Apr 2019 10:31:13 +0200
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [netmod] 6991bis: address-with-prefix-length
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Apr 2019 08:31:36 -0000

Per Hedeland <> writes:

> On 2019-04-18 10:41, Ladislav Lhotka wrote:
>> On Thu, 2019-04-18 at 10:09 +0200, Kristian Larsson wrote:
>>> On 2019-04-18 09:40, Ladislav Lhotka wrote:
>>>> Juergen Schoenwaelder <> 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.
>>>>>> ^^^^^^^----- 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 rather than, 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.
> Agreed - except the not entirely minor nit that the thing after the
> "/" is not a prefix but a *prefix-length*. Another way of putting it

Yes, you are right, mea culpa.

> is that the IP address is a property of an interface, while the
> prefix-length or subnet mask is a property of the network that an
> interface is connected to.
> So this would clearly be two separate values "bundled" into one, and
> despite the similar syntax, it is radically different from the
> existing ip*-prefix types, which really do represent a single value -
> as Kristian pointed out earlier in the thread, the value is the
> initial N bits of a set of IP addresses - i.e. a prefix, as the name
> says.
> Thus if these types should be added, I don't think there is any reason
> to have a naming that is "consistent" with the existing ip*-prefix
> types - rather the naming should highlight the difference. And since
> the two values given are an IP address and a prefix-length, the
> natural choice would be ip*-address-and-prefix-length.
> Using ip*-address-and-prefix would be both inaccurate (neither of the
> two values is a prefix, although they can of course be combined to
> compute a one) and IMHO confusing due to the similarity in naming of
> the existing ip*-prefix types.
> If ip*-address-and-prefix-length is considered too verbose/clunky
> (although I don't know why this matters for a type name), a reasonable
> shorter form could IMHO be ip*-address-and-length - the prefix-length
> is of course a length, but it is not a prefix. Kristian's
> ip*-address-and-plen is of course even shorter, and could be
> considered to have more information, but I believe we generally try to
> avoid at least non-obvious abbreviations in the YANG modules.
>>> 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.
>  From a data modelling perspective, having separate leafs for separate
> values should be the natural choice, and I don't think anyone is
> suggesting that the "bundled" type, if added, should be used in e.g.
> RFC 7277. A grouping could be nice, but it is still two separate
> leafs.

Yes, and it is IMO how it should be. As Martin pointed out, complicated
lexical representations are difficult to deal with, e.g. in XPath

> This is no solution to Kristian's problem, which as far as I
> understand is about having a YANG model for existing devices that
> already *use* the "bundled" type, i.e. it "needs" to be a single leaf
> in the YANG module.

I doubt this is a real problem - a netconf/restconf server backend can
easily translate the two separate leaves into a single string if
necessary. Backends on other devices may well need to use the IP
address and mask separately.


> Whether this need is enough motivation to actually add these types to
> ietf-inet-types I don't really know. There is no real cost in doing it
> per se, but it could have the negative consequence that it is taken as
> an encouragement/"blessing" to use these types when writing new
> modules that *don't* "need" to use them. Bad from a data modelling
> perspectve, and bad for the operational reasons that Martin gave an
> example of while I was writing this. But maybe the 'description'
> statement could warn against this.
> --Per

Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67