[dtn] BPbis registry values

Brian Sipos <BSipos@rkf-eng.com> Tue, 23 June 2020 22:25 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 591FE3A0BFC for <dtn@ietfa.amsl.com>; Tue, 23 Jun 2020 15:25:02 -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_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zFwRJB2-Sn-J for <dtn@ietfa.amsl.com>; Tue, 23 Jun 2020 15:25:00 -0700 (PDT)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2085.outbound.protection.outlook.com [40.107.220.85]) (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 8743F3A0A73 for <dtn@ietf.org>; Tue, 23 Jun 2020 15:25:00 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LsG0GMYRuMQ10ln4/1U5/jXq4KR435c52slbYAxhVTJpxUz6vdR5k68jmO23Ml73+QzT4EG2CdDAMF7ykdy7qf76ayWIzl2Ix91U3PoloD7thMKccKmnxHKI2Fi/qson6mmHXRN4rmDdWlJV2XWDHmCBs7s519xjq6b9NdUbNKWmaJwKGLw5ynogxvKzKODXwpwVaOI8i+Eb5bA1/U/jETdonQ6MFCvP17IAW1xwHkirYvtdOlVbu4nkXeVuFsLDjq8Yicr1MZdni0ZiXBtJ/Sf7XgEZmuaDwZQ7bauJCmcl7WH/PJpwDPTYkVzIcf14zkUT/n31kgKqOsNeYxd58w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4pBpnhJ4jX/kbpEt9xM1Bl6DIYaI3+u5RmEuKBuyzCU=; b=j3Jz/6in5qCj6AV0HclENTzOVoA2mxW2cFHBB28RWSkLFWBqr3y4rTnG3fqKroSF+GVYthhexQ79GkRlJS3LJpbYcO1eSKmIrMJuK/bWUOXDo+uINOeBd/PbOdALskNcQq13nCLk7CXo6ApsZnUEaCADD+dhjj1sAqxGuWM4xlWy6ZA8+CwytxUCuY9HCRFvEDY8PBsb5DRSFTA08RUl92R7KwHbGCwwL/Tz7ZdhFRnmlVEaAd1mffF9aZYVmbmmvayuOvJwsLtwlN69fqOjt6EZgS7p9k1HhCDZWxSJW3KFewS5EhVDC5NfgSrc2KDlaXY9cV1rhl0trzqjr/o/rg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rkf-eng.com; dmarc=pass action=none header.from=rkf-eng.com; dkim=pass header.d=rkf-eng.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rkfeng.onmicrosoft.com; s=selector2-rkfeng-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4pBpnhJ4jX/kbpEt9xM1Bl6DIYaI3+u5RmEuKBuyzCU=; b=SYcu1TB8DTbR89ZtIg0y2nHeQ9usweCOzyd14kYujRXDghzjih7l+iQh10S5KXzSJ7OWAZg/sFlECieDoP45ZAgHK+8cYeFvAZol/CRG5oDzah+VN67tPOIFNEXxG00OwmMeJ816BF9r4Khj6WtSxlwYU/ZbMKP4/RIaaCPxBf4=
Received: from MN2PR13MB3567.namprd13.prod.outlook.com (2603:10b6:208:168::10) by MN2PR13MB2656.namprd13.prod.outlook.com (2603:10b6:208:e9::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.13; Tue, 23 Jun 2020 22:24:58 +0000
Received: from MN2PR13MB3567.namprd13.prod.outlook.com ([fe80::2d35:414:84c4:d1c5]) by MN2PR13MB3567.namprd13.prod.outlook.com ([fe80::2d35:414:84c4:d1c5%5]) with mapi id 15.20.3131.018; Tue, 23 Jun 2020 22:24:58 +0000
From: Brian Sipos <BSipos@rkf-eng.com>
To: "dtn@ietf.org" <dtn@ietf.org>, "scott.c.burleigh@jpl.nasa.gov" <scott.c.burleigh@jpl.nasa.gov>
Thread-Topic: BPbis registry values
Thread-Index: AQHWSP6PMz3+3T8plUKtz/MvaM50YQ==
Date: Tue, 23 Jun 2020 22:24:58 +0000
Message-ID: <MN2PR13MB356772C843319A7E4A27361B9F940@MN2PR13MB3567.namprd13.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=rkf-eng.com;
x-originating-ip: [108.18.140.127]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9912c666-f256-49eb-54b2-08d817c4435d
x-ms-traffictypediagnostic: MN2PR13MB2656:
x-microsoft-antispam-prvs: <MN2PR13MB2656B5F191E1DED68258AD269F940@MN2PR13MB2656.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 04433051BF
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0a4TdzpkAQtFCCJTJDdsj2C6ZFpqWf/LsLNQUu06y3++jDgk4Envjruipvpa82mNjYx/56L7UkyETZIegJQ+PeNllfcinpfxAHrioUcZz4yqU7kau/K8m+qMKT35833vOqocPa59RmWR05ODSiE1MQrGZTSiKKsBaEstgIxJMBXHmln0y9Opez65xQKg6XDHV8+vKX1aRozIbRBV0gHXcgDspOzMVxDLyXlnyKqUVo9paCM6C+8GcecfRwjOtx5upTVYgIwwvbifRtoH7EU+DG3wKFRPirKswDEWYodmyL9ZYGROoQLioIl8QgH+cMq1aEEJ7/y8BUlvmuo1oanSiuAK5FJTnQv8BUNPjXRrunyoP62fXZeyYxck6v11oTrXjSH+aJ6Op6SnGH7tBhbTbg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB3567.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(376002)(346002)(396003)(136003)(39830400003)(366004)(86362001)(166002)(66476007)(66446008)(71200400001)(66556008)(110136005)(316002)(64756008)(8676002)(508600001)(52536014)(3480700007)(19627405001)(66946007)(76116006)(8936002)(5660300002)(2906002)(966005)(7116003)(9686003)(83380400001)(186003)(33656002)(7696005)(26005)(6506007)(55016002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: ilhbqgu/Cgyfk/72gfMoa4oooKw1NI79dzXpdN7Cg4SjhGyZCuG508QmLX7leiwu131O9ywNovgFz+b8MkVa2e28BqWCzIIqGNwkDVUa4b7tNNIV5xOpYNkjyLYIfU+fHd5mj6VQjr4rxbiWnM/LaZbI/gO0iXaMP03t1F/WpZj0/PwGmh8ZwsXzoP8idbmP+VgYYot5UboacKDFsqkdmt+yERdBm6AXOYbBArYl6wfveEFOOtExwwLv0iHDeC2w43y1nPUv42kCel5NmiYmgnONqEAxwyY5on6XJ0p/ajYuB1lpEHYIP4GqF1rAdjxRGBkTEl+WsOpWq4hhnn2+I2xxoqPrwfUSTvct6vor5xFGb27TCInR06jQELsZUYtu0eEHEhofuEcqNUl+KuSATcevOds+9rS3W+PpX3SE9eRB3XhmttY8LnXvuZstgb8G1hwmZjFt7LTkdlv7oS21yi/ANIORcNAsEoGw3OdPOxydIHwP+QKbIXUp1Q2pJiQf
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR13MB356772C843319A7E4A27361B9F940MN2PR13MB3567namp_"
MIME-Version: 1.0
X-OriginatorOrg: rkf-eng.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB3567.namprd13.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9912c666-f256-49eb-54b2-08d817c4435d
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2020 22:24:58.0965 (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-CrossTenant-userprincipalname: vBFMH2ENRjjQ0CAz6B/GpRS2Gy1qjSYugq5cosFRyy8Ps5EiiTSEU/8SNs8s7w6KTUgHGAFYMWq0Aavdc4SfpQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB2656
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/GHiFOfNvmSbIUUPkxhSeD4Li5fc>
Subject: [dtn] BPbis registry values
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: Tue, 23 Jun 2020 22:25:02 -0000

Scott,
Similar to an earlier DTN mailing list comment about the "dtn" scheme definition not including the "dtn:none" SSP value in the ABNF of [1], does it make sense to allocate an IANA registry of other well-known and integer-encoded SSPs for the dtn scheme? The initial registry would have the value 0 for "none" but it could be helpful to have integer-encoded values for other well-known (fixed-value) SSPs. This is in line with how other protocols use CBOR to have 'tstr' values be more free-form while 'uint' values map from a registry of well-known values.
I was looking into a similar well-known value for neighbor broadcast addressing ("dtn:neighbor" or similar concept).

Also, although the Administrative Record Type sub-registry has not changed for BBv7, would there be value in reserving a block of the higher code points (not available in BPv6, due to its fixed-length encoding) for private or experimental uses? This would be similar to the reservation of block type codes 192-255. I was doing some drafting for a new administrative record type and not having a specific range of code points to experiment within makes it more likely to cause interoperability troubles.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpbis-25#section-4.1.5.1.1
[2] https://www.iana.org/assignments/bundle/bundle.xhtml#admin-record-types