Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block

"Christian M. Amsüss" <christian@amsuess.com> Thu, 18 February 2021 13:31 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B91F3A1209; Thu, 18 Feb 2021 05:31:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34kEmk4IQOO0; Thu, 18 Feb 2021 05:31:47 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D673A1200; Thu, 18 Feb 2021 05:31:44 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3016A40887; Thu, 18 Feb 2021 14:31:42 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 52C14FD; Thu, 18 Feb 2021 14:31:41 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C608B190; Thu, 18 Feb 2021 14:31:40 +0100 (CET)
Received: (nullmailer pid 826586 invoked by uid 1000); Thu, 18 Feb 2021 13:31:40 -0000
Date: Thu, 18 Feb 2021 14:31:40 +0100
From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= <christian@amsuess.com>
To: supjps-ietf@jpshallow.com
Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org, core@ietf.org
Message-ID: <YC5sPGW0TD/PybvD@hephaistos.amsuess.com>
References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <YCxikyadpukaiK5I@hephaistos.amsuess.com> <004601d705f8$acbec250$063c46f0$@jpshallow.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Jd9hOaZ5pb197ncl"
Content-Disposition: inline
In-Reply-To: <004601d705f8$acbec250$063c46f0$@jpshallow.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/AifO4ywCJDJ2NtT-45VzqpgnwWc>
Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2021 13:31:50 -0000

Picking a quick one because I don't know when I'll get to the rest:

> > * 4 the new 4.08 format: Since this is a CBOR sequence, the
> >   implementation note on telling the array length in advance does not
> >   apply. As for the CDDL, I don't know whether the array format is OK to
> >   use for the sequence, or whether the CBOR
> 
> [Jon] Not sure what you are trying to ask here.  I know we removed the
> Request-Tag from the CDDL which may have changed things.

If the array were sent in CBOR, indeed the sequence 1, 10, 20 would look
like this (courtesy of cbor.me):

83    # array(3) <--- here is where you need to know the length in advance
   01 # unsigned(1)
   0A # unsigned(10)
   14 # unsigned(20)

But as the content format is a cbor-sequence one, what you actually send
is this:

   01 # unsigned(1)
   0A # unsigned(10)
   14 # unsigned(20)

(No array header, just a sequence of self-delimited items).

So now the implementer's worst worry is that if they start writing an
item in the last byte and the item needs a u16 they gotta roll back, but
that is simple. Picking the array length in advance would be hard (and
the implementation note's suggestion of not exceeding 23 items would
apply), but by using a CBOR sequence you're already free of that.

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom