Re: [dtn] [EXTERNAL] MTCP PDU Length Field
"Burleigh, Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov> Wed, 27 March 2019 05:45 UTC
Return-Path: <scott.c.burleigh@jpl.nasa.gov>
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 0B6CD120247 for <dtn@ietfa.amsl.com>; Tue, 26 Mar 2019 22:45:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jpl.nasa.gov
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 I4GTrpDxBYKZ for <dtn@ietfa.amsl.com>; Tue, 26 Mar 2019 22:45:32 -0700 (PDT)
Received: from ppa01.jpl.nasa.gov (ppa01.jpl.nasa.gov [128.149.137.112]) (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 CC863120243 for <dtn@ietf.org>; Tue, 26 Mar 2019 22:45:32 -0700 (PDT)
Received: from pps.filterd (ppa01.jpl.nasa.gov [127.0.0.1]) by ppa01.jpl.nasa.gov (8.16.0.21/8.16.0.21) with SMTP id x2R5ijE1092866; Tue, 26 Mar 2019 22:45:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=jpl.nasa.gov; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=JPL1810; bh=ztgTruIrdWbr994kIX3RIuNbBqcbTM11I+0NhoBqxg8=; b=eyE0uUHOjeAVFajQ4KjitLrr5mAv0ffyRbw/99N4ZVwpA3zCtR3S6NCuf1UrPFTPsJZE huPdjbzyH6MLS0DcTqFy4ByBha+EcqmZeO26/scLtQUUL9Ao0xn+WgGoXdqLvjYJMHJx IXXR7dSAnvYXA46AdVdV75LKIJF/xmh5sw5FtKGcdsQUjhQud73XjHO7s0CRropcPD6+ j0WtaznQZB0o12HyfgJ5PZaJtj1cBEPVN+vPxSVE0jD9novVjQPiObxjaPRdplZYBPcz AxkbzeABz4quDDtOmE8jhBXJcjcLiK8qkSPJc4O1c+6nabDZ4NiKZHqndWYgR8ig28eA sg==
Received: from mail.jpl.nasa.gov (altphysenclup01.jpl.nasa.gov [128.149.137.52]) by ppa01.jpl.nasa.gov with ESMTP id 2rfqn2jarq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Mar 2019 22:45:27 -0700
Received: from mail.jpl.nasa.gov (ap-embx16-sp10.jpl.nasa.gov [128.149.137.83]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id x2R5jPNU023942 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified OK); Tue, 26 Mar 2019 22:45:26 -0700
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Tue, 26 Mar 2019 22:45:25 -0700
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.1531.008; Tue, 26 Mar 2019 22:45:25 -0700
From: "Burleigh, Scott C (312B)" <scott.c.burleigh@jpl.nasa.gov>
To: Felix Walter <felix.walter@d3tn.com>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: [EXTERNAL] [dtn] MTCP PDU Length Field
Thread-Index: AQHU5AbGoQpWvdmB3km5JAP31Lj1M6Ye8zHQ
Date: Wed, 27 Mar 2019 05:45:25 +0000
Message-ID: <2709f70e5a23461d8eb19487dce7847c@jpl.nasa.gov>
References: <edcd852f-a381-2dfa-8c39-bc4df3eecc56@d3tn.com>
In-Reply-To: <edcd852f-a381-2dfa-8c39-bc4df3eecc56@d3tn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp10.jpl.nasa.gov [128.149.137.83]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-27_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903270040
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/5OW7os3J9-h1GGPESg1GuRsH89E>
Subject: Re: [dtn] [EXTERNAL] MTCP PDU Length Field
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 27 Mar 2019 05:45:35 -0000
Hi, Felix. Yes, I agree. Looking back at our discussion of this topic in mid-January in the context of BP blocks, I think I simply didn't take the consensus far enough: declaring the block-type-specific data to be a single definite-length CBOR byte string (no separate data length field needed) in BP was correct, but MTCPCL protocol data units should be formatted in the same way -- the separate data length field is not needed. I'll make that change. Scott -----Original Message----- From: dtn <dtn-bounces@ietf.org> On Behalf Of Felix Walter Sent: Tuesday, March 26, 2019 12:03 PM To: dtn@ietf.org Subject: [EXTERNAL] [dtn] MTCP PDU Length Field Hi, Concerning draft-ietf-dtn-mtcpcl-00: As mentioned in the WG session today I wondered whether the length of the serialized bundle is required as a separate array item in the MPDU (see [1]). According to the CBOR spec [2], the encoded byte string already contains a length. >From an implementation perspective, having an additional length field should not be a problem: Both values encode the length of the encapsulated (serialized) bundle and, by that, do not depend on each other. (You may remember the discussion about the bundle block data length field last year where this was the case. This was also the reason why I stumbled upon this when reading the draft again.) Thus, if I'm not mistaken, couldn't we reduce the MPDU to a single definite-length CBOR byte string? Felix [1] https://tools.ietf.org/html/draft-ietf-dtn-mtcpcl-00#section-3.2 [2] https://tools.ietf.org/html/rfc7049#section-2.1 -- Dipl.-Ing. Felix Walter Chief Technology Officer D3TN GmbH E-Mail: felix.walter@d3tn.com Web: https://d3tn.com Address: D3TN GmbH Leon-Pohle-Str. 2 01219 Dresden Commercial Register: District Court Dresden Register Number: HRB 34957 VAT ID Number: DE303348407 Managing Directors: Marius Feldmann, Paul Seidler _______________________________________________ dtn mailing list dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn
- [dtn] MTCP PDU Length Field Felix Walter
- Re: [dtn] [EXTERNAL] MTCP PDU Length Field Burleigh, Scott C (312B)