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@xxxxxxxxxx> > Sent: Friday, January 19, 2024 1:08 PM > To: Joseph Touch <touch@xxxxxxxxxxxxxx>; tsv-art@xxxxxxxx > Cc: draft-ietf-dtn-dtnma.all@xxxxxxxx; dtn@xxxxxxxx; last-call@xxxxxxxx > 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@xxxxxxxxxx > 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
