Re: [dtn] Robert Wilton's Block on charter-ietf-dtn-01-00: (with BLOCK and COMMENT)
Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> Sat, 30 October 2021 19:15 UTC
Return-Path: <zaheduzzaman.sarker@ericsson.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 900DD3A1233; Sat, 30 Oct 2021 12:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, 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=ericsson.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 HPlDHwjPCPxr; Sat, 30 Oct 2021 12:15:28 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2047.outbound.protection.outlook.com [40.107.21.47]) (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 987393A122F; Sat, 30 Oct 2021 12:15:27 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IecSTvI82r6pUIHfUUemHPTZ4v1knwfJ7d4o+JlN4gKVFF7/TQ9vemCOWlamcDzVqsAiJpgUI/dfq2g9JTKeNscYnUapA645MXtFnq9G9yuVrYsoHozXVJWa8G8RxNBkIcejtYyKBClXlQpvIKE0NFFHftrdHANPuk/mtmbZoAKP9U5nwzDutxy8cHrBcLjUrm6dbDAuihPSxiw2o19SXeIf6X0T6xEQn+r1OfCnV5hXoYYIG4VFRlBDIHnJN/PjQxqHmvEHy0JWIN+XbwVL4hpADcUd2RQ47xfRBsigTLq2yIw/l2NQtvvT3vaSzmNNmP2NP5rgYza86NnrW5WWSw==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ez19Dxz3TP2tXE4zYoAfjsi4bIYotP9mXo121xO2jbQ=; b=Zssyt82Q9NDeZjs9iOQ+GQIxEJznpqvC1Qh1VLN5HF3IOmxQjxnlLptB1r8cVJUHd0zuXALn7sAgb+1sYzXouWUQmcb4Q7WdyS+IIb0F73WJbaczIBAx03mSTfsa73aB/t/R4RLNhP5vTkO+qjDAMhOk34ii2L0uMXmEoiPlO3ygjKHWkMgl87rwJ5j7PtpCkiOrh7Wpb7SGz8CqpQQrEvvnrFLHeL3+yWwwkOlkPaiREbgnwEF+v9lCWNPgIg57L7bCfs+zFfjqiKax+JqEH5r9+ugGf5DYU6g0Kr7VeAbWFrSsfZBFeLi3fPSiJTrRcV4zS82ol/PhUjQgEQCNKw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ez19Dxz3TP2tXE4zYoAfjsi4bIYotP9mXo121xO2jbQ=; b=sJENInOWi4CtRvChVgFnE41VvsPyiTBMJVtv5Zaj3RdHuic+2a17oqaI/2od4l/hImd5GPSMIirLJyV9vtwax686pPlAAIJtDpJbuRR1dOSF+pQmtk3LhPX50mo7neu46mH8qea+ENlRVGKSCF2X2q6fU2NTDfyDulkvDyGeQiE=
Received: from HE1PR07MB4187.eurprd07.prod.outlook.com (2603:10a6:7:98::23) by HE1PR0701MB2700.eurprd07.prod.outlook.com (2603:10a6:3:92::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.5; Sat, 30 Oct 2021 19:15:20 +0000
Received: from HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::9458:17fc:2f2f:70e7]) by HE1PR07MB4187.eurprd07.prod.outlook.com ([fe80::9458:17fc:2f2f:70e7%6]) with mapi id 15.20.4669.006; Sat, 30 Oct 2021 19:15:20 +0000
From: Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>, 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: AQHXqIJsmwOw9AXAnEeGMENLpyJdcaujavEAgAAe8YCAAw/cgIAH792AgASDW4CAOUiAgA==
Date: Sat, 30 Oct 2021 19:15:19 +0000
Message-ID: <1A5D8BEC-86E8-4EC8-9D54-AEFE38943992@ericsson.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> <MWHPR1101MB22221B73F3FE6CCE26B5CC47B5A49@MWHPR1101MB2222.namprd11.prod.outlook.com>
In-Reply-To: <MWHPR1101MB22221B73F3FE6CCE26B5CC47B5A49@MWHPR1101MB2222.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.54.21101001
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 344a85e1-eeb1-471b-d1ec-08d99bd99d5d
x-ms-traffictypediagnostic: HE1PR0701MB2700:
x-microsoft-antispam-prvs: <HE1PR0701MB27001F64BBC9D0F405E5DAED9F889@HE1PR0701MB2700.eurprd07.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: RTdRLL3oQ9S1/aGt87U8JUH+EL1A7aaPBmwfS9CLhH8giOQexkXKtR+K1ywzvZH0QB/Z/GnguTAIZzmxMmHqAjLVXpMtUHEQMLX//1IBksMiaTO75gB1xEuAd+z6LuuzC7V9wqF0gJz2fC3XPkFi3GkCj1FTy7rUY9XNUiz7RKwZTeMI5hcj32G7rbLm42XWhWmWYjMAcodkvf63EWBMg042SQXbrtkV5ShEa6BwD/Uw2ARgIZq9BY2BPDWYwfFBG3PZ7l8hrBGEmzU+E9TONw0kHVFMXM4JqvvO6CoDMI7iadv675I9h/z8c73+1YQZM6bZPuP3CRLTMOPYjGV3IyR8ijuxHv/6FpNQ3/JrBWEKCGFDigl9EDwFGqrNzESUdovGNIIBYpjUisSu7PD042OeiluBMUpq6UMoOfFD4if7yplCnHH5TB4hjC1teIBFeKUuzhdBoHLnjzT714uepqJxg9N6E8hUTUwXw+rb7dFNGs2pi9GpWrw3D8J2Z++2twX30/gazkkVFYYac/amuIqSc2ZhseGtXkB4ghO6K/SnwKtusnAxYzYDBCl/NAM9YXclOvKfobebRzcQoCiuVRncylZQJCjofJqnwka388pbSB6FNNMnJYm27fDpbhGgwZcvDT4rBu9egrXm9+Ha9ovEzwGSCFtwEZ/23Zh200abm+cb+X90Pahawnsoi2HKHEjHV0vL11GhymdwXKTk6y467X/vVzeoLyFJWmpHORjAtBNHOB9Dm7Tv6EhS5BcA+ns2XFnad6Q/Ke0Wij7MzMCXpyhOy0PTFKsN5fE1joY91OmV91aeitB57iW1ZxrHd75pMNqhi1U1bbWTY5+4o32WXxSTnw2aO3wEK8s6q8g=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4187.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(83380400001)(38070700005)(53546011)(26005)(66446008)(110136005)(966005)(33656002)(6506007)(186003)(66556008)(6486002)(508600001)(64756008)(66476007)(8936002)(44832011)(36756003)(40140700001)(30864003)(4326008)(316002)(54906003)(71200400001)(6512007)(5660300002)(76116006)(2906002)(91956017)(122000001)(82960400001)(66946007)(86362001)(2616005)(38100700002)(8676002)(45980500001)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: aAerLClosIV5Yvs3O+vZPWrfjXIAFUQCrmCYd1Pj28DmEBkIRaxHiuVugsCVB4W9/y/YL3aSeZEPFJZC3ea30lHBP48mhK0F9/tNcfwztDaT/sFpQ01mfQF7KHtH5Ov+0RG+izC6g7Ij8NAx4xVOZyRXu27PtJLVD0dZiat5seRWhfnogdj97PZOaBrSAO+Cb+VDKthgoNI2IU/6WlwGlmNIqgxRtkrkZxp5PYFbIQ4Zjvq3ECfVcmgOZjSdsHBON3Wj4fpvxE54dAyeV3inAzkqU2v4Vq7vTPa0adIikIUBsVCy1aBPSQVlvErwmx3q6hdsNLKPulQmw8DwrnoJNDUMreElQ5AiAOP5L91KiIzkv+BpOoxaWFPPhSXOaVfhwiMpJmGt75T8Z3qMJNRL7ouArVBIk1kBA0+HbFy6tySsn7Snl7YXMUsdhngzncGX8vGNeMdMLbqAZXmkYTE/Ke8HDt2SA5zb6mgsxg/Dc8QadAh3o7CTOLRcB7ZbqqBlq7QgH8KZzs+TK+xJFVtZjxG8RA0AoqIOEfDs6qYm8pDuWdpASZrIYPmcSo2EbR6wo8BZn5BVNE00nfILP+EEh642QxdPG9cv/k8Jjz1/D3mVon3xnYvsR6IjqBKBqHe64jebQUUyZBeoo2PHpfTb07NmbTuMPVTi1ZTWIYeER3/4IAmUalG/+whXe5gKqDD8zpFsTZs9NKmg9A53p2GazxPnW1nIt/tmTWDxzAFhR6tB/g28bh8tVmVuvhKe6RQWbFvapcnnOOkzr8SSJVPkydIkN6UGoOChvA4eex5UCnkgXBD97UZ/41fO42SHGU6QNCw5P+5PLgtaqm0tw8jC0c4zZyqHLfXxoa2Ixm5QXUnBoDufWHZCwD3oZepnJREKB/VUuWLtAZ7rJE2ES6AGxv3gxHaLBF06kiyNk9rGwvLs306fpSgYMdT2PHjbIbRl/N6ig1vs+LhXn/xHybsE+Ybxo8orhRNIUZwXOswYKrZkE4SJzOiq2BMcIY6vIstWMq/e2NrVgh++QP7wwzm+F7PBOxnxjbC78MeAKJSeliJFGzeLerVRQ+ytT/Xg/N8BJOmoBOY3VUVdJOPgL7RFjgYtdaa9UWwwLOlIGT8dxmLlxi40kF0VxwkMAAhluL6krlmW81/11nTop7hfEdhgmYuFn0Gx9AhBYEmFBGrOVR2/nofbTNydIGAQZ3O6+Og2mZ4V5NeKlnAiggDSqdGEZI+jdETnLnht5pVIg/W/vO42a8EQUJvvWKlkdKDRGOfC6Lb9lKRogGFN30wVw380OkdktBT5Me78GQT7v9aLKq8kFYs0bhLAMFM3MIx9wB3wPCBknPq8Vb2IBmFR2S0aNlO4SplZTXJk9PQA5ItdWTQNA1koCcShwaic39BZWxojSUwFC2IH2kMgzLZBqMNe8yCljqGaEkQOmv4VLRXNxlccqgzyMmQfavofqJoDOSsuBuu51ZL+R83eew0P0F5Yh1vXXr0WPX2G4QK4P3GsxTZnPUDKMsLIKlppm9PvbOx1UOJNdxPMq2IxKNivpjgqTl9cRZu8nU4r0so3uSjxolvaRSMBpb4oU6tAlSRhzfUuc1VzIt/BULFmWLzAdiWFytzRW9VsbzgCyNIk2nzTr/bKbrGXRu8SOdr9pTpmV7htrxm3gwKyvLBezqeOebXW1Hn8x5u9Udo6vTyA0zY5oIiV5f4chJGRnXHug6w2rrw6rdNAr3do1EZFTlTUVk/BSw==
Content-Type: text/plain; charset="utf-8"
Content-ID: <A784B48953891E41A879AB970E5D4BB8@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4187.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 344a85e1-eeb1-471b-d1ec-08d99bd99d5d
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2021 19:15:19.7177 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Crx8dnEo3YTZD/Q13FFuOCi6skQe3pekQUewRnY82SIuDBD/0yhV8QjmKL2C+M7LGrAdq7jRr6ymm9UmuOTIc3shrhx6Rc34zMQyBqjmE9u2AoPpdJRZkUfNIxdrI/zQ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/qxi0AN9mdod8ZP-r7aGmSGNwBIk>
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: Sat, 30 Oct 2021 19:15:33 -0000
Hi Rob, I think the updated rechartering text (https://datatracker.ietf.org/doc/charter-ietf-dtn/ ) addresses your comments and reflects the way forward. Please have a look. BR Zahed On 2021-09-24, 12:29, "Rob Wilton (rwilton)" <rwilton@cisco.com> wrote: 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