Re: [dtn] [EXT] Tsvart last call review of draft-ietf-dtn-dtnma-08

["Birrane, Edward J." <[e-mail]>]

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. <[e-mail]>
> Sent: Friday, January 19, 2024 1:08 PM
> To: Joseph Touch <[e-mail]>; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Alert-Verify-Sender: RE: [EXT] [dtn] Tsvart last call review of draft-
> ietf-dtn-dtnma-08
> 
> APL external email warning: Verify sender [e-mail]
> 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