Re: [dtn] BPv7 CDDL and CBOR tagging

Brian Sipos <BSipos@rkf-eng.com> Sat, 06 April 2019 20:04 UTC

Return-Path: <BSipos@rkf-eng.com>
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 4296412008D for <dtn@ietfa.amsl.com>; Sat, 6 Apr 2019 13:04:12 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rkfeng.onmicrosoft.com
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 VyM3lgYH5Cdb for <dtn@ietfa.amsl.com>; Sat, 6 Apr 2019 13:04:09 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740083.outbound.protection.outlook.com [40.107.74.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0E0120046 for <dtn@ietf.org>; Sat, 6 Apr 2019 13:04:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rkfeng.onmicrosoft.com; s=selector1-rkfeng-com0i; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wdkw2G4GMPHtVqUW+qJiF/vaRLXLzsg3pZYyxggn7Ko=; b=Ofgu1v2R4WTtTPfzygJQFAo86BFV3rYGHb8NVpAJV9/Cf+ISo6LPwenv/uc0zWETsTYQN6HheHuLpWE7vrE4QbM8aDquhQonPaI3XZu8E1RZmCg+/cimO5W9jEkthLe3oLsS3k23ecIc2YnSYTH+gn6vBCOLe+40MpodDjjr8Hw=
Received: from BN6PR1301MB2034.namprd13.prod.outlook.com (10.174.90.143) by BN6PR1301MB1891.namprd13.prod.outlook.com (10.174.86.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.7; Sat, 6 Apr 2019 20:04:05 +0000
Received: from BN6PR1301MB2034.namprd13.prod.outlook.com ([fe80::1d56:b599:e2f6:f260]) by BN6PR1301MB2034.namprd13.prod.outlook.com ([fe80::1d56:b599:e2f6:f260%7]) with mapi id 15.20.1771.011; Sat, 6 Apr 2019 20:04:05 +0000
From: Brian Sipos <BSipos@rkf-eng.com>
To: Carsten Bormann <cabo@tzi.org>
CC: "dtn@ietf.org" <dtn@ietf.org>, Scott Burleigh <scott.c.burleigh@jpl.nasa.gov>
Thread-Topic: [dtn] BPv7 CDDL and CBOR tagging
Thread-Index: AQHU6cwkKjg/bVi0S06SSCrlH9F6SKYvE+yAgABD1fw=
Date: Sat, 06 Apr 2019 20:04:05 +0000
Message-ID: <BN6PR1301MB2034D9BCA00BDB59840649919F520@BN6PR1301MB2034.namprd13.prod.outlook.com>
References: <CY4PR1301MB20399B0DD6B59D2D566257379F570@CY4PR1301MB2039.namprd13.prod.outlook.com>, <988AFDDA-BEA9-4533-ADD7-CA86CCA755EF@tzi.org>
In-Reply-To: <988AFDDA-BEA9-4533-ADD7-CA86CCA755EF@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=BSipos@rkf-eng.com;
x-originating-ip: [73.250.91.32]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 316db815-ae58-4b35-2d09-08d6bacb05b2
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:BN6PR1301MB1891;
x-ms-traffictypediagnostic: BN6PR1301MB1891:
x-microsoft-antispam-prvs: <BN6PR1301MB1891D94169C442C3825224B99F520@BN6PR1301MB1891.namprd13.prod.outlook.com>
x-forefront-prvs: 0999136621
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39830400003)(396003)(366004)(376002)(346002)(189003)(199004)(508600001)(5660300002)(33656002)(8936002)(74316002)(54896002)(6246003)(9686003)(8676002)(53546011)(14454004)(6506007)(105004)(71200400001)(80792005)(19627405001)(229853002)(26005)(71190400001)(476003)(486006)(76176011)(6916009)(7736002)(97736004)(446003)(7696005)(11346002)(25786009)(186003)(55016002)(72206003)(6436002)(105586002)(52536014)(256004)(102836004)(53936002)(54906003)(316002)(3846002)(6116002)(4326008)(81166006)(68736007)(2906002)(66066001)(81156014)(99286004)(106356001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1301MB1891; H:BN6PR1301MB2034.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: rkf-eng.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: uzWFtGTtbXrDqBLXaiQvEBXBmhPJsluZAI8bXIk2ITfVyycM09xggc5m7xy/1zLU9FBmgjbzkjPNvChKRiz671S7J9JeEQ3QanvTovtQbfMndvbaXyt3yDbikoCIadTfPF4TlwdNw9B8afNcyclXPz+wWQyHX1/JFQBveTtfdmZkl0nfG4h5j+FzvmlYFHUv+2zsNoTZt/ZrHvTKUPST+zZpHO9yI27ImNN/62BOpWzZRr4jnxuS93FvL5+Z1cLDR54a3FbPtj3Zy5wnyiwnFOaw1zF0umr4eSVoI98Pm46Y5XTa2UflgEUKecdmo4TJV7bysKUUbpwAJrh7lbSSDJq2hw/sVhZLH0gBIbfA+IrPPk/fxfv8kgZPCucxBfUv8xbvwekUY+XmX3QtzEjpqfR6X0ZIv2+LQfZLrHv6xtA=
Content-Type: multipart/alternative; boundary="_000_BN6PR1301MB2034D9BCA00BDB59840649919F520BN6PR1301MB2034_"
MIME-Version: 1.0
X-OriginatorOrg: rkf-eng.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 316db815-ae58-4b35-2d09-08d6bacb05b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2019 20:04:05.5314 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4ed8b15b-911f-42bc-8524-d89148858535
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1301MB1891
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/NaKYFIFybII8zrzr0YLWivIZe8g>
Subject: Re: [dtn] BPv7 CDDL and CBOR tagging
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: Sat, 06 Apr 2019 20:04:12 -0000

Carsten,
My purpose of marking these potentially-tagged items in the CDDL is less for the BP agent encoder implementer to say "where should tags be" but for the bundle troubleshooting / validating tool implementer to give indication of "where may tags be" to have some value. The CDDL itself is all informational, so it's not an issue for the BPv7 spec itself.
The actual value in the tags themselves is not for the BP agent (the agent would just skip over the tags, as neither changes the block-data semantics of the tagged-item), but for troubleshooting with non-BP-specific tools.

I had earlier brought up to the WG the question of whether there is any value in registering a BPv7 media type. That was seen as unnecessary since bundles should only appear in a BP context (either at-rest or on-the-wire) and CBOR encoding itself already has a media type. I think a BP-specific tag would have the same amount of support, which is why my suggestion for a content-type hint on an encoded bundle is just the "yes it's CBOR" tag.

________________________________
From: Carsten Bormann <cabo@tzi.org>
Sent: Saturday, April 6, 2019 08:25
To: Brian Sipos
Cc: dtn@ietf.org; Scott Burleigh
Subject: Re: [dtn] BPv7 CDDL and CBOR tagging

On Apr 3, 2019, at 21:14, Brian Sipos <BSipos@rkf-eng.com> wrote:
>
>        • Indicate some likely places where CBOR tags can be used to augment encoded bundles for troubleshooting. In my mind, the reasonable tag sites are:
>                • Tagging the whole bundle as "#6.55799(bundle) as a sentinel for content-type-scanning tools.
>                • Tagging the "block-type-specific-data" as "encoded-cbor = #6.24(bstr)" when it is in fact CBOR.
>

Hi Brian,

can you indicate what the purpose of the tagging would be?

Tagging the whole bundle as 55799 would identify it as a CBOR data item, but not yet really as a bundle.  If the purpose is to facilitate working with generic CBOR tools on the data items, that may be useful if there are other formats flying around in the same space the bundle is being used.  If the purpose is to identify this as a bundle, why not go for a specific tag just for bundles?  55798 is still free…  Or any number that is even more visibly tagging (such as 25200, which would be visible in a hex/ASCII dump as ‘bp’, or maybe four-byte or even an eight-byte number).  I understand these tags would be stripped off for actual transmission through a convergence layer?

The encoded-cbor tag (24) is great for identifying embedded CBOR, but what do you do for the other kinds of block-type-specific data?  Sorry, it’s been a while since I looked in detail into the bundle protocol.

(Why is the CDDL in appendix B double-spaced, by the way?)

Grüße, Carsten