[dtn] "Block data length" field in BPbis
Felix Walter <felix.walter@tu-dresden.de> Fri, 23 March 2018 16:22 UTC
Return-Path: <felix.walter@tu-dresden.de>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BA412DA09 for <dtn@ietfa.amsl.com>; Fri, 23 Mar 2018 09:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 5OyvEM957CTG for <dtn@ietfa.amsl.com>; Fri, 23 Mar 2018 09:22:26 -0700 (PDT)
Received: from mailout6.zih.tu-dresden.de (mailout6.zih.tu-dresden.de [141.30.67.75]) (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 B4D7112D96B for <dtn@ietf.org>; Fri, 23 Mar 2018 09:22:26 -0700 (PDT)
Received: from mail.zih.tu-dresden.de ([141.76.14.4]) by mailout6.zih.tu-dresden.de with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <felix.walter@tu-dresden.de>) id 1ezPSR-0004qC-GB for dtn@ietf.org; Fri, 23 Mar 2018 17:22:24 +0100
Received: from [141.30.247.101] by server-40.mailclusterdns.zih.tu-dresden.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (envelope-from <felix.walter@tu-dresden.de>) id 1ezPSR-0006c4-53 for dtn@ietf.org; Fri, 23 Mar 2018 17:22:23 +0100
From: Felix Walter <felix.walter@tu-dresden.de>
Organization: Technische Universität Dresden
To: dtn@ietf.org
Message-ID: <ce643b57-1765-c189-0c2d-5fbe5f573548@tu-dresden.de>
Date: Fri, 23 Mar 2018 17:22:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-TUD-Original-From: felix.walter@tu-dresden.de
X-TUD-Virus-Scanned: mailout6.zih.tu-dresden.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/QseT8KqA7AVUotfq8v_ME0FtUZI>
Subject: [dtn] "Block data length" field in BPbis
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Mar 2018 16:22:29 -0000
Hi, We just had a short talk with Scott, Ed, and Rick about the "Block data length" [1] field of the canonical block in BPbis that I would like to forward to the list. As far as I understand it, this value is the count of (serialized) bytes still belonging to the block, but following the length field. Because CBOR is used for the block-type-specific data, the length field by itself is redundant. For example, in the payload block, it will always be followed by a "CBOR byte string" representing the payload data. (This contains a length as well.) It needs to be considered in implementations that all these length fields are variable-length themselves - however, this turned out to be no big issue. I also see the point of having the "Block data length" available to the parser, to be able to skip over the whole block data of complex extension blocks without even parsing them. Are there any further reasons for having the "Block data length" available which I have missed? Or does anyone have a strong opinion on whether this should be removed or kept? By the way, the language concerning the "Block data length" should probably be modified slightly as it refers to "[...] the aggregate length of all remaining fields of the block, i.e., the block-type-specific data fields.", though, this may (now) be followed by the CRC checksum. Felix [1] https://tools.ietf.org/html/draft-ietf-dtn-bpbis-10#section-4.2.3
- Re: [dtn] "Block data length" field in BPbis Felix Walter
- [dtn] "Block data length" field in BPbis Felix Walter
- Re: [dtn] "Block data length" field in BPbis Burleigh, Scott C (312B)
- Re: [dtn] "Block data length" field in BPbis Felix Walter
- Re: [dtn] "Block data length" field in BPbis Marc Blanchet
- Re: [dtn] "Block data length" field in BPbis Felix Walter
- Re: [dtn] "Block data length" field in BPbis Clark, Gilbert J. (GRC-LCA0)
- Re: [dtn] "Block data length" field in BPbis Matt Wronkiewicz
- Re: [dtn] "Block data length" field in BPbis Clark, Gilbert J. (GRC-LCA0)
- Re: [dtn] "Block data length" field in BPbis Brian Sipos
- Re: [dtn] "Block data length" field in BPbis Clark, Gilbert J. (GRC-LCN0)
- Re: [dtn] "Block data length" field in BPbis Birrane, Edward J.
- Re: [dtn] "Block data length" field in BPbis Burleigh, Scott C (312B)