I am an assigned INT directorate reviewer for . 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/ . 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