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

supjps-ietf@jpshallow.com Thu, 18 February 2021 16:40 UTC

Return-Path: <jon.shallow@jpshallow.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 809863A1429 for <dots@ietfa.amsl.com>; Thu, 18 Feb 2021 08:40:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CICMCESZxxi9 for <dots@ietfa.amsl.com>; Thu, 18 Feb 2021 08:40:22 -0800 (PST)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B322D3A1425 for <dots@ietf.org>; Thu, 18 Feb 2021 08:40:18 -0800 (PST)
Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from <jon.shallow@jpshallow.com>) id 1lCmIy-0005Tw-LR; Thu, 18 Feb 2021 16:37:28 +0000
From: supjps-ietf@jpshallow.com
To: christian@amsuess.com
Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org, core@ietf.org
References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <YCxikyadpukaiK5I@hephaistos.amsuess.com> <004601d705f8$acbec250$063c46f0$@jpshallow.com> <YC5sPGW0TD/PybvD@hephaistos.amsuess.com>
In-Reply-To: <YC5sPGW0TD/PybvD@hephaistos.amsuess.com>
Date: Thu, 18 Feb 2021 16:37:32 -0000
Message-ID: <00f901d70614$5ab51b50$101f51f0$@jpshallow.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAHVBsU8AgePCMYCKEdkN6jNWQ8Q
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/ullX-kh01qYus3QA0S-obmrfk4o>
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 16:40:27 -0000

Hi Christian,

We are following https://tools.ietf.org/html/rfc8742#section-4.1 here.  CDDL
does not support a notation for top-level CBOR sequences so have gone with
the recommendations of this section.

As CDDL defines it as an array using the documentation text "This defines an
array, the elements of which are to be used in a CBOR Sequence:", I am
thinking that we need to keep it as an array.

I guess that we need an expert understanding of what to do here.
- Maybe leave out the CDDL definition and give an example?

Regards

Jon

> -----Original Message-----
> From: Christian M. Amsüss [mailto: christian@amsuess.com]
> Sent: 18 February 2021 13:32
> To: supjps-ietf@jpshallow.com
> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org; core@ietf.org
> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block
> 
> 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