Re: [Tsv-art] [EXT] [dtn] Tsvart last call review of draft-ietf-dtn-dtnma-08
"Birrane, Edward J." <Edward.Birrane@jhuapl.edu> Fri, 26 January 2024 16:19 UTC
Return-Path: <Edward.Birrane@jhuapl.edu>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CEEC14F6BE; Fri, 26 Jan 2024 08:19:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAfJz6ngIsAX; Fri, 26 Jan 2024 08:18:56 -0800 (PST)
Received: from aplegw01.jhuapl.edu (aplegw01.jhuapl.edu [128.244.251.168]) (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 6EED2C14F5EE; Fri, 26 Jan 2024 08:18:56 -0800 (PST)
Received: from pps.filterd (aplegw01.jhuapl.edu [127.0.0.1]) by aplegw01.jhuapl.edu (8.17.1.19/8.17.1.19) with ESMTP id 40QCiXYV007938; Fri, 26 Jan 2024 11:18:55 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=JHUAPLDec2018; bh=HqYOlMQGtDTPJWXBcpCQZT1iokdFIAcCyYJviOT09ZA=; b=C/BFKNaa8+bvtxPHPJrnAn0IHfcTfwQTecqf34eZQUc47Swze1Txhq/slJGF3kL65JNq TRWLemnU8aQvY3gOPGOmHsmXJm+woHVmzu9beFIwo0d0+WxjCahI4ko7zPoNAwCDcOJM XBPesAZK37bcZx/bGWJM9zb+SHC95hO1T8YxQSN179S7jnclTq6OsAPj1kwU6VVlx7iZ eYKTAPMYM3bp+dYBC9LUUwOCNP6uAYiju5GW0uFwVrC72tAYYVIOQYnEgGaUlKRh+n7O 1VZD6vZ/cMa/4ProNhn9q2XRoeX0LZBIHnU79fSkhxfAwiMB491vS0ByUYR+zcVBuE8T UQ==
Received: from aplex20.dom1.jhuapl.edu (aplex20.dom1.jhuapl.edu [10.114.162.5]) by aplegw01.jhuapl.edu (PPS) with ESMTPS id 3vr83egsf5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Jan 2024 11:18:55 -0500
Received: from APLEX21.dom1.jhuapl.edu (10.114.162.6) by APLEX20.dom1.jhuapl.edu (10.114.162.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.40; Fri, 26 Jan 2024 11:18:54 -0500
Received: from APLEX21.dom1.jhuapl.edu ([fe80::6032:607c:9f2a:6daa]) by APLEX21.dom1.jhuapl.edu ([fe80::6032:607c:9f2a:6daa%5]) with mapi id 15.02.1118.040; Fri, 26 Jan 2024 11:18:54 -0500
From: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>
To: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>, Joseph Touch <touch@strayalpha.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "draft-ietf-dtn-dtnma.all@ietf.org" <draft-ietf-dtn-dtnma.all@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: [EXT] [dtn] Tsvart last call review of draft-ietf-dtn-dtnma-08
Thread-Index: AQHaRdK8IOMpZjP/A0+hOXX7+Tac1bDhZs9wgArz7LA=
Date: Fri, 26 Jan 2024 16:18:54 +0000
Message-ID: <3cc27f7676b549dcacce6c1ba20fabc2@jhuapl.edu>
References: <170511743396.29205.7361219212467742875@ietfa.amsl.com> <9bdc9be28829415ca892e6230cabcb7c@jhuapl.edu>
In-Reply-To: <9bdc9be28829415ca892e6230cabcb7c@jhuapl.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.162.19]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CrossPremisesHeadersFilteredBySendConnector: APLEX20.dom1.jhuapl.edu
X-OrganizationHeadersPreserved: APLEX20.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-25_14,2024-01-25_01,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/tWkVINbcrlxl7idpeNqivZ0t7Kw>
Subject: Re: [Tsv-art] [EXT] [dtn] Tsvart last call review of draft-ietf-dtn-dtnma-08
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Jan 2024 16:19:01 -0000
All, A -09 version of the document (https://datatracker.ietf.org/doc/draft-ietf-dtn-dtnma/09/) has been posted that implements the changes discussed below. -Ed Edward J. Birrane, III, Ph.D. (he/him/his) Chief Engineer, Space Networking Space Exploration Sector Johns Hopkins Applied Physics Laboratory (W) 443-778-7423 / (C) 443-690-8272 > -----Original Message----- > From: Birrane, Edward J. <Edward.Birrane@jhuapl.edu> > Sent: Friday, January 19, 2024 1:08 PM > To: Joseph Touch <touch@strayalpha.com>; tsv-art@ietf.org > Cc: draft-ietf-dtn-dtnma.all@ietf.org; dtn@ietf.org; last-call@ietf.org > Subject: Alert-Verify-Sender: RE: [EXT] [dtn] Tsvart last call review of draft- > ietf-dtn-dtnma-08 > > APL external email warning: Verify sender Edward.Birrane@jhuapl.edu > before clicking links or attachments > > Joe, TSVART, > > Thank you for taking the time to review this informational document and to > provide comments on where we can clarify or improve the work. > > My replies are in-line below. To help with discussion, I tried to enumerate > comments so replies are prefaced with "EJB_#" where # is the comment I am > responding to. > > To summarize, we would propose 3 changes to the existing document, to > clarify intent: > > 1. Clarify this informational document does not imply an implementation OR > an implementation architecture (EJB_4) 2. Remove unused terms from the > terminology section (EJB_5) 3. Define the term "timely" based on its use in > the document (EJB_6) and use the term to clarify end-to-end where > appropriate (EJB_8). > > > ----- > > > First, it claims to focus on operating devices in challenged > > environments, but does not specifically rely on DTN protocols. That > > seems to imply that DTN protocols would not be sufficient, which begs > > some questions – if DTN is not useful here (the very case for which it > > seems to have been designed), why not? > > EJB_1: The document does not mean to imply that DTN protocols (namely > BP) are insufficient and we try to address this in the document. For example, > the abstract states: "This document describes a DTN management > architecture (DTNMA) suitable for managing devices in any challenged > environment but, in particular, those communicating using the DTN Bundle > Protocol (BP)" and the introduction states: "The DTNMA is designed to > leverage any transport, network, and security solutions designed for > challenged networks. However, the DTNMA should operate in any > environment in which the Bundle Protocol (BPv7) [RFC9171] is deployed." > > EJB_1: Would it help clarify this if we make a statement such as we would > expect there to be a BP transport binding? > > > > > If not DTN, then what transport would work? > > EJB_2: Reference implementations have used bundle (BPv6 and BPv7) and > also UDP, TCP, and others. There was a proposal to use RMAP for transport > in a very particular circumstance. BPv7 should be used in the cases where > BPv7 is helpful. But locking the DTNMA architecture to BPv7 is unnecessary. > > > > > Second, the implication that this system is useful in the presence of > > unidirectional links alone or that it never relies on query/response > > strains credibility. If there is never a return path, then commands > > might never be received or executed, at which point there’s not much > utility here. > > EJB_3: We may not be using the term "link" in the same way. This document > uses the term link to imply a single-hop. As such, a uni-directional link does > not imply there is no return path. For example, the topology A->B->C->A is a > series of uni-directional links which allow bi-directional communications > between A and C. Similarly the time-variant topology A->C...time passes...C- > >A is also a series of uni-directional links which allow bi-directional > communication. > > EJB_3: Since such topologies do exist in deployed systems it was important > for us to mention that we can run over uni-directional links. > > > > > Sec 1.2 > > - The definition of Reference Model might be more explicit that it does > > not imply an implementation architecture. > > EJB_4: Since this is an informational document we felt this would be > understood. In section 1.3 we describe the reference model as follows: "a > reference model that can be used to reason about the DTNMA independent > of an implementation". > > EJB_4: Would it be clarifying to correct this to say "independent of an > implementation or implementation architecture."? > > > > > Sec 2 > > - if TBR is a simplification of SBR, does that imply that the rule > > stimulus is exclusively relative or absolute time (and thus not dependent > on > > other state?) - If TBR is a simplification of SBR, it would be useful to > > include time, which is not obviously included in the internal state of > > a DA > > EJB_5: Good catch. The discussion around the terms TBR and SBR were > moved from this document to a subsequent document (from WG review) > but the terms erroneously remained here in the terminology section. > Generally, any terms in the terminology section that are not used in the > document should be removed. > > > > > Sec 3.1 > > - Does the lack of round trip communications within a given time imply > > that there might never be a time when this could complete? It would be > > useful to be specific either way (either eventually available or nor > > eventually available). > > EJB_6: In any network a node may cease to function, of course. The "given > time" referred to here (and when we say "timely" in the document) refers to > timelines needed to support synchronous request-response architectures - > such as mentioned in Section 6 when discussing open-loop control. > > EJB_6: We can add a definition of the term "timely" in the terminology > section to help clarify. > > > > > This section should address whether there are any assumptions about > > message reordering, loss, or duplication. > > EJB_7: We felt that (while important) these are characteristics of > implementation architectures and transport mechanism (both out of scope > for this document, from the scope section). However, we can add a > sentence/bullet to this section to emphasize the importance of considering > the impact of message transport on any future implementation architecture. > > > > > End-to-end paths are described as whether they exist at a given time; > > this implies something equivalent to a horizontal line in a space-time > > diagram, where the paths may exist in a way useful to conventional > > protocols as long as they follow end-to-end diagonals along a > > light-cone; this description should be tightened-up, especially given > > such cases are common in cases where DTN is intended to be used > > (interplanetary) > > EJB_8: I agree that causally-connected events in a space-time diagram can be > used to clarify constraints related to signal propagation. But relatively-close > (pun intended?) nodes within a light-cone may fail to meet performance > requirements as a function of configuration. Heartily agree that there is good > reasoning to be done here, but an informational network management > architecture is not likely the appropriate vehicle for that. > > EJB_8: Suggest we tighten the language here to use the term "timely" (which > I suggested adding in EJB_6) and discuss "timely end-to-end". > > > > > Sec 3.2 > > - The topological aspects appear to imply each link is point-to-point, > > rather than (potentially) multipoint bidirectional or asymmetric > > (multipoint in one direction; unicast in the other). > > EJB_9: We did not intend this, and do not believe any wording here prevents > something other than point-to-point. > > > > > Sec 3.2.1 > > - This section should discuss the potential need for idempotency, i.e., > > operations that can be executed multiple times with the same result as > > being executed exactly once. These can include state-dependent > > operations as well as > > inherently indempotent operations. - That issue should be carried into > > section 9.5 on command execution. > > EJB_10: Understand and agree that idempotency is important in an > implementing architecture - and that there are multiple ways of achieving > this. We felt it was better to address this in the context of implementing > architecture (e.g. *not* in this document). Currently other work being > discussed in the DTNWG does, for example, include language on > idempotency. > > > > > Sec 3.2 > > - There should be far more management implications noted here, > > including > > the potential need for idempotency if commands need to be re-issued > > before a confirmation is received. That has implications on the > > command structure as > > well as its execution. - This section appears to imply eventual > > bidirectional communication, again this is not consistent with some of > > the front-matter. > > EJB_11: As an informational document we tried to limit this to the set of > implications that do not otherwise imply an implementation (the importance > of which is noted in a prior comment). > > EJB_11: Also the discussion on bi-directional communication is, I think, > resolved from comment EJB_3. > > > > > Sec 3.3 > > - Again, the notion of one-way management is not useful if exactly as > > presented; there appears to be the need for eventual confirmation, > > which should be noted > > EJB_11: I think we addressed the concept of "one-way" management in > comment EJB_3. Discussions of related questions such as command timing, > command coordination across large numbers of nodes, etc... are considered > to be functions of an implementation and implementation architecture. > > > > > Sec 7 > > - Although this is the core, it is more of a list of useful properties > > than a true architecture. - A architecture should describe the > > components, the interfaces between them, and their individual > > function, describing how they combine to provide a capability. That > > does not appear to be the case here; this is more like a survey of the > > possible components, but there doesn’t appear to be enough information > here to design a system. > > EJB_12: We felt this was the appropriate level of detail for an informational > document. > > > > > Sec 8 > > - The capability appears to be described in sec 8, which seems like it > > should come before the decomposition in this section. > > > > Sec 9 > > - This model appears to be the core of the architecture, more so than > the > > component list in Sec 7; it might be useful to move this earlier. > > Sec 10 > > - Use cases define the model’s aggregate intended behavior, i.e., the > > target. As such, this might be useful to explain before Sec 9, before > > Sec 7, and before Sec 8. > > EJB_13: Regarding the ordering of sections 8,9,10 - we feel the ordering from > less-to-more specific is preferred, but could also add cross-citation if that > would make the material clearer to understand. > > > > > Sec 12 > > - This section seems far too brief; the earlier sections that discuss > > security issues should be cross-cited in extended discussions here. > > EJB_14: We feel this is the appropriate depth as this is an informational > document. Subsequent material built from this would require significantly > more detail. > > > > > Sec 13 > > - If this architecture truly has only one notable reviewer, it might be > > useful to distribute it more widely and obtain more feedback. The fact > > that all authors and the only notable reviewer are all from the same > > organization also begs the question “who is this for”? Has no other > > party or organization contributed to it at all? > > EJB_15: This work has been briefed in the DTNWG, with members outside of > the DTNWG, with members outside of the IETF, and there exist reference > implementations to this architecture in multiple organizations. We do not > see that information as important content of this informational document. > > -Ed > > --- > Edward J. Birrane, III, Ph.D. (he/him/his) Chief Engineer, Space Constellation > Networking Supervisor, Embedded Applications Group Space Exploration > Sector Johns Hopkins Applied Physics Laboratory > (W) 443-778-7423 / (F) 443-228-3839
- [Tsv-art] Tsvart last call review of draft-ietf-d… Joseph Touch via Datatracker
- Re: [Tsv-art] [EXT] [dtn] Tsvart last call review… Birrane, Edward J.
- Re: [Tsv-art] [EXT] [dtn] Tsvart last call review… Birrane, Edward J.
- Re: [Tsv-art] [EXT] [dtn] Tsvart last call review… touch@strayalpha.com
- Re: [Tsv-art] [EXT] [dtn] Tsvart last call review… Birrane, Edward J.
- Re: [Tsv-art] [EXT] [dtn] Tsvart last call review… Zaheduzzaman Sarker
- Re: [Tsv-art] [EXT] [dtn] Tsvart last call review… Birrane, Edward J.
- Re: [Tsv-art] [EXT] [dtn] Tsvart last call review… touch@strayalpha.com
- Re: [Tsv-art] [EXT] [dtn] Tsvart last call review… Birrane, Edward J.