[Tsv-art] Tsvart last call review of draft-ietf-dtn-dtnma-08

[Joseph Touch via Datatracker <[e-mail]>]

Reviewer: Joseph Touch
Review result: Not Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[e-mail] if you reply to or forward this review.

Overall, this document is a bit too vague about its use case, especially the
aspects of the transport protocol over which it expects to operate.

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?
If not DTN, then what transport would work?

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.

Although these deficiencies may originate in other documents (e.g., the BP
definition docs), this doc claims to not depend on BP for its operation. Either
way, this document needs to address these issues.

Some additional notes, some of which are also part of the consideration of the
readiness of this document, notably as an architecture:

The overall document provides a lot of principles and rules, but it isn’t at
all clear that these imply the particular architecture presented. The document
reads less like an architecture and more like a FAQ about issues that might be
addressed, were a detailed architecture presented.

Sec 1.2
-       The definition of Reference Model might be more explicit that it does
not imply an 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

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). If there Is no eventual round-trip confirmation, then it’s not
clear any useful commanding can ever be distinguished from a null event. -     
 This section should address whether there are any assumptions about message
reordering, loss, or duplication. This has consequences later (see discussion
about idempotency). -       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)

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).

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.

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.

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

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.

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.

Sec 12
-       This section seems far too brief; the earlier sections that discuss
security issues should be cross-cited in extended discussions here.

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?