Telechat Review of draft-ietf-dtn-dtnma-10
review-ietf-dtn-dtnma-10-intdir-telechat-eastlake-2024-02-14-00

I am an assigned INT directorate reviewer for
<draft-ietf-dtn-dtnma-10.txt>. These comments were written primarily
for the benefit of the Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat
comments from any other IETF contributors and resolve them along with
any other Last Call comments that have been received. For more details
on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

This document is scheduled for the February 15th IESG telechat. My
apologies for this late review.

In my opinion, this document provides a broad and reasonably complete
view of Delay-Tolerant Network architecture and requirements except as
noted below.


I have the following DISCUSS level issues:
------------------------------------------

Should some action by the DTNMA fail, can this trigger some sort of
failure handling rule? For example, some rule to instantiate some
"safe state"? Error handling guidance seems lacking in this document
but seems important due to the independent nature of the DTNMA.

Related to that, Section 9.2 speaks of bulk updates. Is there a
requirement that those or other actions that result when predicate(s)
are met be accomplished atomicly? Or can things change part way through
some update? If so, does the action "fail" and undo any part already
accomplished or partially complete?


The following are other issues I found with this document that SHOULD
---------------------------------------------------------------------
be corrected before publication:
--------------------------------

It seems to me that a notable absence is a list, even if scattered
through much of the body of the document, of numbered (perhaps
hierarchically numbered) requirements since there are so many
apparently mandatory requirements in this document. It could be argued
that such enumerated requirements are not common in "architecture"
documents. While this is named an "Architecture" document, it is full
of fairly specific and quite stern ("must") negative and
positive requirements. Perhaps it should be renamed "DTN Management
Architecture and Requirements".

There are 35+ uses of lowercase "must" in this document as it
stands. This would be much less a problem if the statements including
"must" were labeled as requirements or they could be reworded using
alternatives to "must" such as "required". The two points at the end
of Section 3.2 are a notable exception in saying "should" rather than
"must".

I'm not sure the possibilities being explored in Section 5 are
evaluated consistently with the mandatory ("must") requirements
elsewhere in the draft. For example, Section 5 may say that some
existing protocol is "a poor choice" when requirements elsewhere
exclude that protocol.

At the end of Section 7.3.3, is it actually correct to say that
responses and commands "are independent of one another"? Hopefully
responses correspond to commands. Perhaps something more like "the
issuance of new commands is not dependent on receiving responses to
previous commands" or even just that "commands and reports are
asynchronous".

In Section 7.3.4, Agent Mappings, it says "only appropriate controls
are sent to a DA". Should "controls" be "commands" or "control
policies?

Section 10, near the beginning, repeatedly refers to "mnemonics" defined
in Section 9 but I don't really see much like that in Section 9.


The following are minor issues with the document:
-------------------------------------------------

Section 4.6, 1st paragraph: I don't think you can "define" elements
"to" a data model. Either used "add" instead of define or "in" instead
of "to".

Although it is pretty obvious that CTRL stands for Control, this
is never defined.

Section 5.3: "exciting" sounds like marketing. Suggesting deleting
that adjective.

Section 10.6, Figure 7: Although this is clear enough with the text, I
think it would benefit to add to the figure, inside the Agent B and
Agent C boxes some indication that they are the sources of EDD1 and
EDD2. Perhaps insering "{EDD1}" and "{EDD2}" insides their boxes
respectively.

Section 11: Since IANA can do other things besides registrations, it seems
simpler and more complete to just say "This document requires no IANA
actions."

Many paragraphs begin with "NOTE: " and or special formatting. This is
so common that it is not clear what this adds. I think in most cases
these could be dispensed with without loss.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com