Re: [Cbor] I-D Action: draft-richardson-cbor-network-addresses-01.txt

Carsten Bormann <> Sun, 07 February 2021 04:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F23A3A2FA2 for <>; Sat, 6 Feb 2021 20:54:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lnT_PVdbOJ4f for <>; Sat, 6 Feb 2021 20:54:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DFF9D3A2FA1 for <>; Sat, 6 Feb 2021 20:54:03 -0800 (PST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4DYGyf3f1QzyWF; Sun, 7 Feb 2021 05:54:02 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <9223.1612672667@localhost>
Date: Sun, 07 Feb 2021 05:54:01 +0100
X-Mao-Original-Outgoing-Id: 634366441.932216-bb0dbd2452c9bbaf9b789d157e253cfb
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <9223.1612672667@localhost>
To: Michael Richardson <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Cbor] I-D Action: draft-richardson-cbor-network-addresses-01.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, 07 Feb 2021 04:54:07 -0000

> On 2021-02-07, at 05:37, Michael Richardson <> wrote:
> Signed PGP part
> Carsten Bormann <> wrote:
>> Nice and sweet (although I liked the sequence in -00 of describing
>> current IP before legacy 32-bit IP better).
> I put current IP (v6) first, and v4 second.
> I don't think that changed.

It did, but in the right direction…
Sorry, misread the diff.
>> There needs to be some text about padding in the prefix byte strings.
>> (Ultimately, a prefix is a bit string, which we decided NOT to have as
>> a basic type in RFC 7049; that would be two bytes shorter if we want
>> that.)
> You mean, if I have 2001:db8:1234::/33  ?  That I need to emit 7 bits of
> zeroes, ideally, and/or that the recipient needs to force those bits to 0.

Leaving these bits open as a side channel would actually give you something to write about in the Security considerations?
The padding bits should be sender MUST be zero, receiver MUST check.
And it probably would be useful to define the preferred encoding to not have more padding than needed.

>> I don’t think the current security considerations are worth it — this
>> security consideration applies to any self-describing representation.
>> (And inversely, in a signed object you do want to minimize semantic
>> dependencies from context.)
> I don't mind removing it, but having it blank would seem to be lame.

Wouldn’t it be great to, for once, have a protocol-let that has no security considerations?  Oh, you could always say those from RFC 791 (hmm, doesn’t have any) and 8600 apply.

>> I think it would be useful to have some discussion about the
>> pre-existing tags in this space, but that could be done separately
>> (such as in the notable-tags document, for which I need to find time to
>> update it…).
> An appendix that describes previous work maybe?

Works for me.

How useful is it going to be to be able to drop trailing zero bytes?
My intuition is that this creates busywork for the receiver and almost never can be used anyway.

Oh, and the other thing that is missing is a format for transport addresses (i.e., add a port).

Thanks for picking up this subject!

Grüße, Carsten