Re: [dtn] Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and COMMENT)
"Rob Wilton (rwilton)" <rwilton@cisco.com> Fri, 24 September 2021 10:29 UTC
Return-Path: <rwilton@cisco.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 EB8023A22C5; Fri, 24 Sep 2021 03:29:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.599
X-Spam-Level:
X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Qlr6ecLJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nqy2U4Qk
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 CAoafyel8QIJ; Fri, 24 Sep 2021 03:29:16 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23A33A22CC; Fri, 24 Sep 2021 03:29:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35950; q=dns/txt; s=iport; t=1632479346; x=1633688946; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dwZjhlSWQ/I8e/8GE1KwDx9Na/4NH8Z5eIyyVRw1a88=; b=Qlr6ecLJCVx/Cmz0TYPDgrlz2zwFS+A8UoFXJwazUnTRKHfUDG0swTSW YOV4Jh9284OqjLrBaOsI/yWs1SXDSd7rXcY3JDoobJ4dJOEtsQBH2XIje mw80/vcdmCQOpyklXdPqpn6crBynkZaP9arPxNjH0AEVc+rgEldVfYR4T 4=;
IronPort-PHdr: A9a23:HZxkgx+tOWZq3P9uWD3oyV9kXcBvk7f0IwcN7twqh68dOqig/pG3OkvZ6L0tiVLSRozU5rpCjPaeqKHvX2EMoPPj+HAPeZBBTVkJ3MMRmQFzAs6YAFX/avPmcn9yEMFLTlQw+Xa9PABcE9r/YFuHpHq04HYSFxzzOBAzKP7yH9vZjt+80Ka5/JiACzg=
IronPort-Data: A9a23:8dsWqaP/yJCP6UnvrR01lcFynXyQoLVcMsEvi/4bfWQNrUoi32EEyGQXX2DVOvuPMTfyeNBzbNmxoxxSv8XcnN43GnM5pCpnJ55oRWUpJjg4wn8dtEp+F+WbJK5cx5hYOoSowPwcFCeG/0/8aOS59BGQ6InRLlbCIL+cUsxObVcMpBcJ0XqPqsZh6mJaqYHR7zCl4bsel/bi1GqNgFaYBI67B5Wr83uDtNyq0N8RU8dXifpj5DcynFFNZH4TyD3YEpf2fmVUNrbSq+fr1rq1+CbS+A0gT4njmbfgeUpMSbnXVeSMoiMJAO753V4T/Wprj/1T2Pk0MS+7jx2TgNF11NJLnZexUgwueKbLnYzxVjEJSX4gbPIWoeWvzX+X9Jb7I1f9W3fwxd1vAV04e4oC9Y5fDX1IsPcYITEXdTiCiv64hrWhRYFEh8k4I+HqMZ8R/HZ6wlnxF/ctQrjfWaLS5NRR2CwsgdpLBvHQe9UQczcpZxPFCzVdM1caBI8sju6tj3+5aDRCq1+Pjact4mPI1wt3lrPqNbL9V9CVTN9Z2GyZvHjP+WnRABEHPcSbjzeJ7xqRakXn9c/gcJgZGLv9/flwjRjJgGcSExYRE1C8pJGEZoeFc4o3AyQpFuAG98DeLHCWc+Q=
IronPort-HdrOrdr: A9a23:xdyG0q4IKdyLhSzIwQPXwZCCI+orL9Y04lQ7vn2ZFiY1TiXIra6TdaoguiMc0AxhJ03Jmbi7Sc69qADnhOBICO4qTPeftWjdySqVxeRZjbcKrAeQYBEWmtQtsJuINpIOdOEYbmIKzvoSgjPIaerIqePvmMvD6IuurAYOcegpUdAc0+4TMHf8LqQCfng/OXNPLuvk2iMonUvFRV0nKuCAQlUVVenKoNPG0Lj8ZwQdOhIh4A6SyRu19b/TCXGjr1UjegIK5Y1n3XnOkgT/6Knmmeq80AXg22ja6IkTsMf9y+FEGNeHhqEuW3DRY0eTFcBcso+5zXYISdKUmQ8XeR730k8d1vFImjTsl6eO0EDQMkfboWwTAjTZuC6laDPY0LzErXQBepd8bUYzSGqH16Lm1+sMjJ6jlljpxKZ/HFfOmj/w6MPPUAwvnk2ooWA6mepWlHBHV5ACAYUh4LD30XklW6voJhiKorzP0dMee/309bJTaxeXfnrZtm5gzJilWWkyBA6PRgwHttaO2zZbkXhlxw9ArfZv0Uso5dY4Ud1J9u7EOqNnmPVHSdIXd7t0AKMETdGsAmLATBrQOCaZIEjhFqsAJ3XRwqSHrIkd9aWvYtgF3ZEykJPOXBdRsnMzYVvnDYmU0JhC4nn2MS2AtPTWu4hjDr1Cy/PBrZbQQFi+oWEV4r2dSq8kc7/mst6ISeZrP8M=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BBBgC5p01h/5ldJa1QBwMODgEBAQEBAQcBARIBAQQEAQFAgVmBUykoB3daNzGER4NIA4U5iAgDkBCKVoFCgREDVAsBAQENAQE1DAQBAYR9AheCLwIlOBMBAgQBAQESAQEFAQEBAgEGBIERE4U7AQYmDYZCAQEBAQIBEggJEQwBASkOAQsEAgEIEQEDAQEBAgIJGgMCAgIwFAECBggCBAENBQgMBweCBEyCVQMOIQEOoy0BgToCih96gTGBAYIIAQEGBASBNgEDAgIMQYJ/GII1AwaBECqDAIQVgnODfRcQHIFJRIEVQ4FmgQE+gmMBAQIBgR8JAQcKAgECBhoFEAoLDAINglE3gi6Ia0IZBgEbDAYQIAYBAw0VEAkICgICAiACDSkIAQULAwcEAxYcERoGAxAKAQEBDh8BCikRA4wkhH4TCAsJKIMSjGCaYoEZCoMthH2DdYFPjTyBAYYAFINni2iGRZB1liKCHooqk2sEGBdma4MAAgQCBAUCDgEBBoF4JGlwcBU7gmlRGQ9YhzeBD4UCCQMWgQQBDII/hRSFBUV0AjYCBgEKAQEDCZFOXgEB
X-IronPort-AV: E=Sophos;i="5.85,319,1624320000"; d="scan'208";a="927697812"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Sep 2021 10:29:04 +0000
Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 18OAT4mX028617 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 24 Sep 2021 10:29:04 GMT
Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 24 Sep 2021 05:29:04 -0500
Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 24 Sep 2021 05:29:03 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 24 Sep 2021 06:29:03 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ISOJBhTQSf0BF/lEnD8GJgDLCTErnoRlBpYc2A3bJlcEVQWF8d1WU338nxt4w6RBMooDx9JSHhE4N29ZNRwWVWPzEpwRNH1VxUByn0YAlJBKEMPrr3b3qzRQinOaCzUIjYSFpewLTKg5uSax66RXf6CErbYXROalWiKbqKlM6hDSs3ZLWN6Qv6UDe0laZAf0ClHazUWvnk9g4pDXFXNr8yef288F/tFJIUF88YYjlFfO777bDw98Rp+Kl6d5df6V/R4WAktDACTb3DG5o6MxqVFuZo4U7XwWj63tTL8ydb6X2JeKg80zDGhsImW6sFyHDo1R3SY1k6hC6zHxQjz1Vw==
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; bh=dwZjhlSWQ/I8e/8GE1KwDx9Na/4NH8Z5eIyyVRw1a88=; b=gdIWin4UQmihjcKftz3GdWmIB52gFr+SqdFv2AZPofVYTfaTL9xlBoAuXtYV6CuNWjOTdkJib1kRwxQJijCp+WIt5CEeKCRBtgSyz2wqEDkgorji+LOfBWBVW725ppQBx4S8a46/iqZ3s8wmOfCyG1danIZMaLs5m+67n9+QLWZ9jPptX6TreTDhT9gwg6ZE/ZT4z2fiBpekgqGUmtAnJ9Lf7Edwij1f7LNr7ZDz+EMfJfUXfbeL7XY7FAIIpPV+xuiGP1MiaHCfZRIlH4PMUT4QKGxnARBjv3iIdp6oWA2ZEzxQU9WlRDwP6u58O2Bbm4UO90pAq6PqI9SgnOO8yQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dwZjhlSWQ/I8e/8GE1KwDx9Na/4NH8Z5eIyyVRw1a88=; b=nqy2U4QkxlcoeCoA54SSxCkaECQ6eD7/MVMInx4i7a5iOcTNjgxlb1YJM2X5UFBkCD0/DEIKEq/1VDzHgKPB7PoPqpfemA+pTmq4THItfgrtayNsHrRlMUj6Zdltboxb7MmrQNaDqtGodymy42K8n8/Ft/ak78JRgTC+ZT8i9lo=
Received: from MWHPR1101MB2222.namprd11.prod.outlook.com (2603:10b6:301:57::10) by CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.13; Fri, 24 Sep 2021 10:29:01 +0000
Received: from MWHPR1101MB2222.namprd11.prod.outlook.com ([fe80::e4e2:3bc5:c00:4]) by MWHPR1101MB2222.namprd11.prod.outlook.com ([fe80::e4e2:3bc5:c00:4%6]) with mapi id 15.20.4544.018; Fri, 24 Sep 2021 10:29:01 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>, Rick Taylor <rick@tropicalstormsoftware.com>, The IESG <iesg@ietf.org>
CC: "dtn-chairs@ietf.org" <dtn-chairs@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and COMMENT)
Thread-Index: AQHXpV5WzNXMkToBLEKGvQBOErdKoquhufkAgABJUuCAAYzfgIAC7lYAgAgRZICABIMukA==
Date: Fri, 24 Sep 2021 10:29:01 +0000
Message-ID: <MWHPR1101MB22221B73F3FE6CCE26B5CC47B5A49@MWHPR1101MB2222.namprd11.prod.outlook.com>
References: <163118024039.27139.266500820364295413@ietfa.amsl.com> <38A5475DE83986499AEACD2CFAFC3F9801F5B000EF@tss-server1.home.tropicalstormsoftware.com> <DM4PR11MB5438D0D9796E549561C91CF2B5DA9@DM4PR11MB5438.namprd11.prod.outlook.com> <8522a6f4e5644c6a8365ebe1a389f9ca@jhuapl.edu> <4B5AD30A-D376-428E-82D2-01254073AFB2@ericsson.com> <6ec9d1129abe4535b8295459bcd6e162@jhuapl.edu>
In-Reply-To: <6ec9d1129abe4535b8295459bcd6e162@jhuapl.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: jhuapl.edu; dkim=none (message not signed) header.d=none;jhuapl.edu; dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 484bad25-00dd-4566-b5d6-08d97f462062
x-ms-traffictypediagnostic: CO1PR11MB4881:
x-microsoft-antispam-prvs: <CO1PR11MB4881015DB622AD401193B261B5A49@CO1PR11MB4881.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: UXWcXrB7rTu4gGKDmFy8PdsPYyAh3WN2BXmlKgzAODBn6JGiOs6jPtcUg9hkS38HGWceI9U44RL2XMbkSNGBCL34dI4h01nlntfi3Y0k1RU/EHWM12F5MbO4vwNxfwHLV7uxgmdYvOLgEqYuxLhTsiScPguy9eeyH/Cf59oV1Ihsmx/bs8RHvKKYFQ0P1+Tf39tIj3X6tUulrLsqhdG0KgBfdAF8b/RWFXytNrA6epWZjcqyuyNUX5xzjyxMjb/Sc/SwPAZ3VxgaSPcuZLc5F1T9kRMVX3Oaly96JtI0bTIcw+jIu1eiT3xLp4qZUU3I61nkIRbkeM8zBDKFq/j17wlwFkGt3Lt5TQlL8nnpdknEOcXFqSiOeXFRiYaHucsm8CeoolveFJQiL4w/0HzEKcxvpPgOvgHaD7sgPcRJBl22xOELkGd7zCMaI+YinHJeXmYmgy1rXhvNz6Y2u+CJC/1Y4a8nsoWmDiEgxbr+nmGHjSgiInOKGD/0mYlvUojHyW7vkREi5CY6NqVPP7dYP4u2mq/hVEinhWbfB8Al49uEv0wLDDIGaNNxrJ8GOzdzrrBr56cd+6CuDV8cmCN+4I2adKim4V7DPurrK77uD3aFmSloSQtBQdBtxRnyQ62MdHqo15nZ0C1bhfTSugJ6VvpTzp/StXbLYeAfTCl71MWcc4k3Ta00dv1fa81jY+x+YCV8TgCqz0I5bZiCUpVNLJu4//r5sCMSeoofWboRabXxnofJJg0cRsR0WNcD6yg80gJggfo9/T8K1pAaJ39ZQEGL5twpb20ePD6SJFZMEju1TcCdErxGJkmRK2OQQOuJu5d/IlmzCUtSO+Y8Bj/wsA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR1101MB2222.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(38070700005)(8936002)(122000001)(38100700002)(110136005)(54906003)(508600001)(8676002)(26005)(186003)(316002)(71200400001)(55016002)(52536014)(66476007)(40140700001)(76116006)(9686003)(33656002)(66556008)(66446008)(64756008)(2906002)(966005)(66946007)(53546011)(83380400001)(7696005)(4326008)(5660300002)(30864003)(86362001)(6506007)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: JlSq8LhumzXEk4JDPRKpPHj5AZO6ClrrguW0fufIEOGZNNfwLFxItrpOwS80ipfEnvPa3KqPE316HICY+K6YkVnYbNyEfjOhxVZmKw8A7DjSsf3VquOwXIXgyg7fMp/ASIzqFn+ANkP+qwFKKpXly2I6uRFlaeMekyhtgM5OEEFMvBGGUHUNe3kAFYxdyOl/UNmjuDGaI/pPsvsSO+CpAYbTjR7JFYuSaQ/9jlY++7swK0sd2Yee+av/TS/VhYKOPNa0BM8YzZuuJvo0Czlxa4FcT3aaZduAN4gOM/8ueYBvnquASoqnBJffJlmpL7lXmftntsQTVFEsh+ThOggXLfCJbX3zzmT+jn4QJEVz7r89NTw2G2TdXiOItlt5J6XPjjINFH53FZ6Ox6HST2Gd+d6Yn/YnmdXdBWha3mSDmdqcZXL3Wa+fLKE8mNtGSyOkgDxA4BZKcQELzdocMGUHlIeh2W4Uz81OBs+cw5a4+OqeCH+DjQ+7qKFbRemjE/i8mlKAFtk4JJJwkbDHSJiNhp1GUsh6keQx/DemNenqds4z0HljMN94ywAuVerp9XsQ/pA8VZ2duqm204483UYqGcMP8Wi+MTtkApkJt990cB4YTayOtcMh7sKz6VdiU1tBF12hZ2RfE99NO6074N0DDCGgiVXEgsv0CcoXTsjteuONIkzdpSs0hjqhdff3WP/cSzwgsyBoE1ksiD+/OmFjQ7wnfmr0DdneYdtw1f8/Xmz7twQ/hVWCoOoGYuKn4E6iGBQgEsrDcKwieqsVxsx6uOSwNAezpvKc9S/zIZXbiDDjS2GNe8e6iGlyX1H1rFAFrBbz8RtG/QNTt9A/UlH2VOMlkzpdxp6StyZpO0svrNAmwjH2Xc5boE3oOVW72YToSUKV9JXB+zIebgykBlEoTpSz8UCLXuH4uQ9WWcra7lEMdDzu8mPOdrRKimrjaoXNLjp7jiOlkgv9oC5Rflmhy43rQUsNoXCDFd8VSZfjs7EOGCV9217ZdCB6FDdYC6GpJjPH5sXff7qa3xySO0UWEguPmkwO+smKNwiytTnnZQQQAWv+hAp4eaNrNy14LAflEmh/KWQABou1v9hnwE+OrZKT/fF3SCTJfDLWgS0lOu0ypehaMr5x8KjoWDNHe5wi+e+pkury3bQYj1QmUxHDMWNi1UOwbVIrV70AvSUoLkD/TZumLvku1D9+jka+qpG1ZH7tfRSF56Edd386K8m0NYUDGdgfiyLXbaipTvLAxd2dVper/2jKDl3BZC2b9V4tlK+zxir94Yp9FbKZKQM+OjoAem7srj956KhWe2ECYpnJUmubCk3Rz3p+GTG37hmF
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MWHPR1101MB2222.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 484bad25-00dd-4566-b5d6-08d97f462062
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2021 10:29:01.5484 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dCXpqFVNHK1ZabP1TIpeIXlZUdOCdRFrc/ktIzIPtdJs80Wfbzl10U1rBzgnRwWz9ia/qfwu/sd8FyUGoIz0tg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4881
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/Yq9zJi8lcQTjEOMtLhLf1-F0mlA>
Subject: Re: [dtn] Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and COMMENT)
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: Fri, 24 Sep 2021 10:29:22 -0000
Hi Zahed, Sorry for the delayed response, but yes, I think that this is a good way forward. Regards, Rob -----Original Message----- From: Birrane, Edward J. <Edward.Birrane@jhuapl.edu> Sent: 21 September 2021 14:34 To: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>; Rob Wilton (rwilton) <rwilton@cisco.com>; Rick Taylor <rick@tropicalstormsoftware.com>; The IESG <iesg@ietf.org> Cc: dtn-chairs@ietf.org; dtn@ietf.org Subject: RE: Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and COMMENT) Zahed, This all sounds very reasonable to me. -Ed --- Edward J. Birrane, III, Ph.D. (he/him/his) Embedded Applications Group Supervisor Space Exploration Sector Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (F) 443-228-3839 > -----Original Message----- > From: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> > Sent: Thursday, September 16, 2021 6:22 AM > To: Birrane, Edward J. <Edward.Birrane@jhuapl.edu>; Rob Wilton (rwilton) > <rwilton@cisco.com>; Rick Taylor <rick@tropicalstormsoftware.com>; The > IESG <iesg@ietf.org> > Cc: dtn-chairs@ietf.org; dtn@ietf.org > Subject: [EXT] Re: Robert Wilton's Block on charter-ietf-dtn-01-00: (with > BLOCK and COMMENT) > > APL external email warning: Verify sender > zaheduzzaman.sarker@ericsson.com before clicking links or attachments > > Hi All, > > Thanks to Rob for his great review and to Rick , Ed for their responses to the > comments. I think things got a bit clarified and I would like to propose > multiple actions to way forward - > > - clearly there are some confusions on what is specific to DTN and what can > be solved with existing technologies. I am sure in DTN we don't want to come > up with a generic solution problem for the OPS. Hence, we write clear text in > the charter that DTN will only focus on issues related specifically to DTN and > will constantly consult with NETCONF and NETMOD to analyze the solution > based on DTN requirements. > > - for AMA draft, we take it back to the WG, update with gap analysis and > specify DTN requirements. It might also be the case that the term > "asynchronous" is creating some confusion, I may need some bikeshedding. > Even this document has been worked under the current charter, we > continue the work under the new charter and use this document to > communicate the DTN requirement with OPS area. So this goes under a new > work item. > > - The new charter takes on naming, addressing and OPS topics, hence it is > better that we have eyes from the experts on those from early on. For that > in DTN, we make the "early review" a habit. Also try to recruit WG > consultant/advisor(s) from OPS, Routing and INT area if possible. We have > been talking with those area experts in the previous occasions hence we > might already have an idea who the advisors could be. I can work with the > chairs and other ADs for finding interested experts. Another way to find > them could be that we work on gap analysis and requirements and then have > a joint interim with OPS and other related areas. Then we also have fair > chance to see the interests from other areas and get opinions straight. > > - Routing is still out of scope of the current charter, but we point in the > charter that we will be talking with rtgwg, when we discuss topics that relate > to routing. > > If this plan sounds reasonable then I will work the DTN chair to reflect this in > the charter text. So, please send your opinion(s). > > BR > Zahed > > > On 2021-09-14, 15:36, "iesg on behalf of Birrane, Edward J." <iesg- > bounces@ietf.org on behalf of Edward.Birrane@jhuapl.edu> wrote: > > Rob, Rick, > > Thank you for this discussion, and my apologies for not being able to > chime in sooner. > > Rob brings up an excellent point, which is that the "gap analysis" portion > of the existing AMA document was written prior to the standardization of > RESTConf, changes to YANG for IoT, COAP, and others. However, we have > been tracking those changes and (we think) we understand where our needs > are unique in the DTN community. > > Some of our devices are very, very low on resources. Not simply "IoT" > devices, but distributed sensors with environmental energy harvesting, > spacecraft, and microcontrollers. In these cases, lack of compute and lack of > regular power/comms is what makes their operation require delay- > disruption tolerance. We are quite excited, still, about the novelty of some > of our approach in the areas of: > > - No end-to-end communication. Once configured, a node needs to > manage itself. > - A predicate autonomy model (time and state) and not based on > scripting. > - Very terse encodings. I get significant push back adding just 1-2 bytes to > an entire message, much less a single ID. > > Which is not to say we can't have areas of cooperation and coordination! > > - I know of at least one group that is using COAP to carry AMP messages - > they are solving different parts of the problem. > - A masters thesis a few years back was done on the differences between > the "AMP" model and the YANG module, and that student build a YANG- > AMP bridge and demonstrated it at IETF104 > (https://datatracker.ietf.org/meeting/104/materials/slides-104-dtn- > ampnetconf-interop-01). > - There was some effort put into a YANG model of some of the AMP work > (https://datatracker.ietf.org/doc/html/draft-bsipos-dtn-amp-yang-01) > > Some of these are, of course, dated. But... I am fairly confident that as we > go forward we can better identify and deconflict the parts of this approach > which are unique to the DTN community. As Rick mentioned, when we > engaged with other working groups, the message we received at the time > was that the work was interesting, but very niche and not something > particularly applicable outside of the DTN community. And I don't think that > overall sentiment has changed - this is a common DTN management > problem, but not a common network management problem. > > For the charter and initial work, I suggest a few things to help us be much > more clear about how to avoid any kind of duplication or inefficiency: > > 1. The AMA document needs a refresh to include an improved "gap > analysis" of items that came up in the past few years. When we had originally > written AMA we moved on to other work but this is a great place to coalesce > our understanding. I suggest the re-write of the AMA get early OPs review. > > 2. Clarifications to the charter text that any management work on DTNs is > done in ways which are unique to DTN problems and not in areas where > existing mechanisms are sufficient. DTN really does have unique problems > and I think it would not take very long to clarify them. > > 3. Clear text in the charter of example working groups that should be > included in these communications. It has always been our intention (and > desire!) to get more OPs area expertise in understanding our constrained > approach. We have, to date, been far less successful in getting our approach > seen as having enough impact outside of DTN to warrant significant cycles > from other groups who are, understandably, quite busy. > > -Ed > > --- > Edward J. Birrane, III, Ph.D. (he/him/his) > Embedded Applications Group Supervisor > Space Exploration Sector > Johns Hopkins Applied Physics Laboratory > (W) 443-778-7423 / (F) 443-228-3839 > > > > > -----Original Message----- > > From: Rob Wilton (rwilton) <rwilton@cisco.com> > > Sent: Tuesday, September 14, 2021 7:45 AM > > To: Rick Taylor <rick@tropicalstormsoftware.com>; The IESG > <iesg@ietf.org> > > Cc: dtn-chairs@ietf.org; dtn@ietf.org > > Subject: [EXT] RE: Robert Wilton's Block on charter-ietf-dtn-01-00: (with > > BLOCK and COMMENT) > > > > APL external email warning: Verify sender rwilton@cisco.com before > clicking > > links or attachments > > > > Hi Rick, > > > > Thanks for the extra information. > > > > I've put some more comments inline ... > > > > Bringing my conclusion to the top, for this DTN charter cycle I would > suggest > > that it would be helpful for the management aspects of DTN to focus on: > > > > - Documenting the specific requirements for network management in > DTN > > networks. > > - Understanding what aspects of those requirements are not met by > current > > network management protocols (NETCONF, RESTCONF, CORECONF), > YANG. > > - An understanding of whether it would be feasible to extend the > existing > > network management protocols to cover those requirements. > > - Good communication with NETCONF, NETMOD, and CORE WGs as these > > requirements are developed. > > > > I think that once the shape of the solution is better understood it will > > become clear how specific the solution is to DTN and also where is the > best > > place to progress the work. > > > > > > > -----Original Message----- > > > From: Rick Taylor <rick@tropicalstormsoftware.com> > > > Sent: 13 September 2021 10:33 > > > To: Rob Wilton (rwilton) <rwilton@cisco.com>; The IESG > <iesg@ietf.org> > > > Cc: dtn-chairs@ietf.org; dtn@ietf.org > > > Subject: RE: Robert Wilton's Block on charter-ietf-dtn-01-00: (with > > > BLOCK and > > > COMMENT) > > > > > > Hi Rob, > > > > > > Thanks for the comments. I think your block is justified as we need > > > to have this discussion, and hopefully I can clarify a few points. > > > > > > Comments inline... > > > > > > > -----Original Message----- > > > > From: Robert Wilton via Datatracker [mailto:noreply@ietf.org] > > > > Sent: 09 September 2021 10:37 > > > > To: The IESG > > > > Cc: dtn-chairs@ietf.org; dtn@ietf.org; Fred.L.Templin@boeing.com > > > > Subject: Robert Wilton's Block on charter-ietf-dtn-01-00: (with > > > > BLOCK and > > > > COMMENT) > > > > > > > > Robert Wilton has entered the following ballot position for > > > > charter-ietf-dtn-01-00: Block > > > > > > > > When responding, please keep the subject line intact and reply to > > > > all email addresses included in the To and CC lines. (Feel free to > > > > cut this introductory paragraph, however.) > > > > > > > > > > > > > > > > The document, along with other ballot positions, can be found here: > > > > https://datatracker.ietf.org/doc/charter-ietf-dtn/ > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > BLOCK: > > > > -------------------------------------------------------------------- > > > > -- > > > > > > > > Sorry for putting a block on this charter, but the charter for this > > > > WG seems to be moving significantly into the network management > > space. > > > > > > > > In particular, this work seems to be predicated on the assumption > > > > that it better to define a custom management protocol and data > > > > modelling language for the DTN use case rather than reusing, or > > > > extending, the existing network management work defined in > NETMOD > > > > and NETCONF > > > WGs. > > > > This may be the right answer, but it not intuitively obvious to me > > > > that this is the case (some further details provided in the comment > > > > section). > > > > > > I think you're half right here. We have evidence that management > > > protocols designed for an end-to-end connected environment do not > work > > > in a deeply delayed/disrupted network. For example the New Horizons > > > probe floating past Pluto runs a management stack that is a precursor > > > to the work we are attempting to standardise in the WG. That being > > > said, although the existing OPS area protocols appear unsuitable, the > > > data-modelling is most definitely not. > > > > Okay. > > > > I think that it would really helpful to enumerate what the DTN specific > > network management requirements, and whether they can be sensibly > > satisfied by extending the existing network management protocols, > noting > > that there has already been some interest in extending network > > management protocols to support asynchronous messages (but these > would > > probably still expect to see responses in the order of minutes rather than > > hours). > > > > > > > > What we would like to do is to re-use all the great work from NETMOD, > > > but use an alternate transport and processing model more suitable for > > > end-to- end disconnected environments. We are all absolutely agreed > > > that this does not mean discarding/ignoring all of NETCONF/NETMOD > and > > > rolling our own management stack, but it does mean some parts have > to be > > different. > > > > Some parts being different is fine/expected. > > > > But I'm still not quite sure whether what you require for the DTN use > case > > couldn't be accomplished by say extending NETCONF to support > > asynchronous messages, and a binary encoding, and a delay tolerant > > transport. Also, with Alvaro mentioning MANET, I'm trying to understand > > whether what is being proposed is specific to DTN, or more general. > > > > Note, the desire to add asynchronous configuration operations has come > up > > before for NETCONF in draft-ietf-netmod-opstate-reqs-04 (also > referenced > > below). > > There have also been some discussions about adding binary encoding > > support to NETCONF (draft-mahesh-netconf-binary-encoding-01). > > > > I.e., it looks like there is already some interest is enhancing NETCONF to > > cover some of your requirements, but it is not clear to me whether that > > would mean that NETCONF would cover all of them. > > > > > > > > > > > > > (1) There needs to be more discussion with relevant WGs (NETCONF, > > > > NETMOD, CORE) to understand whether the existing network > > management > > > > protocols and data modelling language could cover the DTN use case, > > > > or be reasonably extended to do so. > > > > > > Yes, there does. We have attempted to engage with those groups, but > > > as with all IETF WG's they are busy and focussed on their own topics, > > > and turning up with a weird corner cases is disruptive. Ed and I have > > > had extensive discussions with Dean Bogdanovic over the years, which > > > has helped us understand what is re-useable and what is not - and > > > there is a great deal of cross over with the timed/event-driven config > > > change proposals that reappear constantly in NETMOD - however, we > have > > > failed to attract enough attention to get the work adopted within the > OPS > > area. > > > > I think that providing regular updates to NETMOD and perhaps > > NETCONF/OPSAWG would be helpful. > > > > > > > > > > > > > (2) If there is consensus that the existing IETF management stack > > > > can be reasonably extended to cover the DTN use case, then there > > > > should be discussion about where that work is done, which would > > > > depend on the specific nature of the work. > > > > > > The same argument has been put forward by Alvaro concerning > Routing in > > > DTNs. Yes, there is definite cross-over here, however, we have a > > > really productive (small) WG that is focussed and keen to continue > > > working on these topics, and would rather not dilute the enthusiasm by > > > moving this work into another area. This does not preclude constant > > > communication and peer-review with the relevant WGs in other areas, > > > but we believe for this charter cycle the authoring should remain in > > > the DTN WG, even if Transport isn't really the correct area. In the > > > future, yes, let's split the work into the correct areas, but > > > currently we do not have the huge interest to support such > fragmentation. > > > > I find it hard to know where the work should be done, because I don't > have a > > good feel about what shape the solution should take. > > > > > > > > To this end, we are adding a mandate to the end of the charter to > > > force the WG to work closely with the relevant areas on each > > > cross-over topic, and for management that is definitely NETMOD. > > > > I think that this will be NETMOD for the use of YANG, and possible > NETCONF > > for your new management protocols, or extensions to the existing > NETCONF > > management protocols. > > > > > > > > > > > > > (3) Otherwise, if the consensus is that an entirely separate > > > > management stack is appropriate, then I think that the solution > > > > needs to be tightly constrained to the DTN use case, and not framed > > > > as a generic asynchronous management architecture. > > > > > > We don't believe it is appropriate, and I am actively pushing back > > > against a bespoke solution for DTNs. We must be able to re-use YANG > > > modelling, and best-practice from NETCONF, even if XML-over-SSH is > not > > > the correct transport. In my mind AMA could be rebranded as > DTNCONF: > > > fundamentally the round-trip time and the transport is the issue - the > > > rest is 'just' good old data modelling. > > > > > > > > > > > Rob > > > > > > > > > > > > -------------------------------------------------------------------- > > > > -- > > > > COMMENT: > > > > -------------------------------------------------------------------- > > > > -- > > > > > > > > Looking at the charter, and specifically at draft-ietf-dtn-ama-01, > > > > Asynchronous Management Architecture (which is in DTN WGLC), it > > > > seems to be built on the following assumptions: > > > > - network management is generally synchronous > > > > > > Not necessarily 'synchronous', that might have been a bad choice of > > > word, but definitely end-to-end connected: I can send 'do this' and > > > pretty promptly I can get an acknowledgement. In a DTN, this > assumption > > does not hold. > > > > I believe that some network management architecture for managing > 'regular' > > networks is effectively also moving in this direction. > > > > E.g., if a controller is trying to update the configuration for 10k devices, > then > > trying to manage that a distributed transaction, or synchronously update > > each device, isn't the best model. > > > > > > > > > > > > > > > - A different data modelling language (i.e., not YANG) is required > > > > to model asynchronous management data > > > > > > Fair criticism. The original work was done in isolation and was based > > > on an SNMP-like approach. Since then much work has gone into > moving > > > to a more NETMOD transactional approach, but there is still work to > > > do. At their core the current drafts expect a tree-like data model > > > that can be modified, so mapping to YANG is entirely feasible, and > > > this an area where we definitely need help. > > > > > > > > > > > - There are no efficient encodings of management data modelled in > > YANG. > > > > > > I'm not sure this is correct. I think the original authors looked at > > > NETCONF > > > 1.0 and worried when they saw lots of XML on the wire. > > > > Yes, but as above, there has already been some interest in whether > adding a > > binary encoding to NETCONF could make sense. > > > > > > > > > > > > > > > But I don't think that these assumptions necessarily hold: > > > > - NMDA, RFC 8342, was architected with a goal of supporting an > > > > eventual consistency model (specifically, supporting a temporal > > > > separation between sending the desired configuration to a device > > > > and the device enacting that > > > > configuration) > > > > > > We (I) am unaware of this work, and I suppose that underlines the > need > > > for better communication between the WGs. This 'temporal > separation' > > > is an important part of management in DTNs (where the round-trip > time > > > may be hours), but there is a need for autonomy as well which may go > > > further that RFC 8342 (I need to go read it). > > > > I would suggest that you also have a look at: > > draft-openconfig-netmod-opstate-01 - the background precursor to this > > work draft-ietf-netmod-opstate-reqs-04, which also covered > requirements > > for asynchronous configuration operations. > > > > If you have questions on this, then let me know. > > > > > > > > > > > > > > > - In addition to NETCONF, there are also the RESTCONF and CoAP > > > > management interface protocols that could be considered. > > > > > > We have looked at both RESTCONF and CoAP. RESTCONF suffers the > same > > > problems as NETCONF because it requires a bidirectional end-to-end > > > connection, but the CBOR encodings in CoAP are really useful - the > > > numbering system is odd, but there is a lot that can be reused. > > > > The key points of the numbering system is: > > - scope the IDs globally rather than relative to the parent. > > - encode them efficiently (because CBOR encodes smaller numbers in > less > > bytes). > > > > In theory, for streaming telemetry data, you could end up sending this as > a > > set of tuples of the form (global-id, keys, value), where the global-id > > represents the path, the keys are to any list items in the path from the > root > > of the schema to the leaf being returned. > > > > > > > > > > > > > > > - YANG Push, RFC 8641, allows for subscriptions to be notified of > > > > when data changes, or periodic updates. I.e., entirely push rather > > > > than > > > pull. > > > > > > We have spent a lot of time with Eric Voit as he was first proposing > > > YANG- Push. The concepts are similar, and there are lots of parts > > > that can be re- used, but it's more of a 'call me back when something > > changes' model (i.e. > > > just restarting the end-to-end connection) than what is needed in a > DTN. > > > What we really need is YANG-Post, i.e. "send me a mail when > something > > > happened, telling me what you just did" > > > > YANG Push is the latter, i.e., either a receiver, or through configuration, a > > client makes a subscription on the server that says: > > - send me the new data, whenever any of these data nodes (or their > > children) change (perhaps dampened) > > - or periodically send me the new data for these data nodes (or their > > children). > > > > A client would not be expected to make a get request when it is notified > of > > new data, there is no need, since the notifications already contain all of > the > > relevant data. Putting aside the underlying transport, the data flow from > > server to the receivers is logically asynchronous, it is just a stream of data. > > > > > > > > > > > > > - YANG just models data and that should have no bearing on whether > > > > the protocol mechanisms used to move that data are synchronous or > > > > asynchronous. > > > > > > Completely agree. > > > > > > > > > > > - The CBOR and CBOR SID encodings of YANG data encode the data in > a > > > > compact binary format. > > > > > > Completely agree. I personally think the CBOR-SID numbering is a bit > > > weird for IOT reasons, but there is definite opportunities to align. > > > The DTN stack is built on CBOR, so it should be a no-brainer. > > > > > > In conclusion: I think you raise a good list of points that should be > > > discussed before anything DTN management related is standardised. > > > Some we have considered, some we have not, but either way we must > > make > > > sure that there is good communication and peer-review between the > > > WGs/Areas. As I've said above, purely to keep up the good > momentum we > > > have in the current DTN WG, I do not want to split the work out - but > > > it should be considered when the WG next re-charters. In the > meantime > > > we will mandate that the management documents must receive early > > > review by the OPS area, and the chairs will ensure that WG does not > > > disappear off to make bespoke management solutions, as long as the > > > relevant OPS Area WGs can find the cycles to help us avoid mistakes? > > > Ironically Alvaro has also expressed an interest in seeing the AMA > > > work done in the Routing Area, as it addresses some charter items for > > > the MANET working group - so we really are spanning many areas here > - > > > but I firmly believe we need to grow more before we can consider > > reorganisation. > > > > Yes, hopefully that aligns somewhat with my suggestion at the top of my > > reply? > > > > Thanks, > > Rob > > > > > > > > > > Cheers, > > > > > > Rick
- [dtn] Robert Wilton's Block on charter-ietf-dtn-0… Robert Wilton via Datatracker
- Re: [dtn] Robert Wilton's Block on charter-ietf-d… Rick Taylor
- Re: [dtn] Robert Wilton's Block on charter-ietf-d… Rob Wilton (rwilton)
- Re: [dtn] Robert Wilton's Block on charter-ietf-d… Birrane, Edward J.
- Re: [dtn] Robert Wilton's Block on charter-ietf-d… Zaheduzzaman Sarker
- Re: [dtn] Robert Wilton's Block on charter-ietf-d… Birrane, Edward J.
- Re: [dtn] Robert Wilton's Block on charter-ietf-d… Rob Wilton (rwilton)
- Re: [dtn] Robert Wilton's Block on charter-ietf-d… Zaheduzzaman Sarker
- Re: [dtn] Robert Wilton's Block on charter-ietf-d… Zaheduzzaman Sarker
- Re: [dtn] Robert Wilton's Block on charter-ietf-d… Rob Wilton (rwilton)
- Re: [dtn] Robert Wilton's Block on charter-ietf-d… Birrane, Edward J.
- Re: [dtn] Robert Wilton's Block on charter-ietf-d… Zaheduzzaman Sarker
- Re: [dtn] Robert Wilton's Block on charter-ietf-d… Rob Wilton (rwilton)
- Re: [dtn] Robert Wilton's Block on charter-ietf-d… Rick Taylor