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
