Re: [Cbor] I-D Action: draft-ietf-cbor-network-addresses-04.txt

Carsten Bormann <> Sun, 25 April 2021 15:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E2813A1701; Sun, 25 Apr 2021 08:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2MfALRxTk84G; Sun, 25 Apr 2021 08:30:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C15163A16FF; Sun, 25 Apr 2021 08:30:16 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4FSsR94zQfzySd; Sun, 25 Apr 2021 17:30:13 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Sun, 25 Apr 2021 17:30:13 +0200
Cc: Michael Richardson <>,,
X-Mao-Original-Outgoing-Id: 641057413.204631-678098a5db77b1125362e352a981a0f8
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <12496.1619216560@localhost> <>
To: Ole Troan <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] I-D Action: draft-ietf-cbor-network-addresses-04.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Apr 2021 15:30:20 -0000

> - for 261 I would at least include those arguments and make it clear when to use or the other

Sounds good to me.

> - so you don’t want to support the commonly used shortcut of specifying both and address and a prefix in one?

That is a valid point.
But I think the data should indicate whether they are just a prefix or an address and a prefix.

> - in ip agnostic code I often find I just need an IP address instead of having to care if it’s 4 or 6. It would therefore be nice with a general IP address and ip prefix type too. 

If I understand this right, we already have that.  One type with two different tags…
(CBOR doesn’t have “types” [except for the “major types” on the representation level].  You are free to construct your own types in your implementation, e.g. construct a “Boolean” type from “true” and “false”.  In your case, the “IP address and prefix” type would include values with either tag 52 or 54.  We could define recommended CDDL types, like we did in Section 5 of RFC 8746...)

Grüße, Carsten