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 tsv-art@ietf.org 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?