Re: [dtn] Comments on DTNMA draft-ietf-dtn-dtnma-03

["Heiner, Sarah E." <[e-mail]>]

Hi Alberto,

Thank you again for your thorough review of the DTNMA and continued support of this work. I appreciate you taking the time to write out your comments and have included my responses in-line below. Version 04 of the DTNMA is being worked now and we will reflect this feedback in the update.

Thanks,
Sarah
From: "Alberto Montilla (SPATIAM)" <[e-mail]>
Date: Thursday, November 10, 2022 at 6:35 PM
To: "[e-mail]" <[e-mail]>
Cc: "Heiner, Sarah E." <[e-mail]>, "Birrane, Edward J." <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [dtn] Comments on DTNMA draft-ietf-dtn-dtnma-03

First of all, Sarah, Ed, Emery, fantastic work in updating this draft. We enjoyed reading the document. Please find below the detailed questions/suggestions and comments on the document for your consideration.

Regards;
Alberto


[Suggestions & comments]

  *   Page 1 – Abstract (this one is a follow up of the conversation during IETF 115 session) The architecture could apply to any challenged environment, however it states “…in particular, those communicating using the DTN Bundle Protocol (BPv7). Operating using BPv7…” Let me say I agree with the statement, however I would suggest expanding it to all versions of the Bundle Protocol. This is spread through the document. I would suggest making it generic to the Bundle Protocol (no version) as much as possible. Do a search and you will find many occurrences. This is also future protection.

SEH: Is there a particular sentence or section in the DTNMA you feel says that BPv6 is not supported? While the DTNMA does reference BPv7 specifically, I don’t see any language that excludes the use of BPv6. In this informational document, we are describing the environments in which BP would be deployed, regardless of version.


  *   Page 12 – Section 4.1 Suggest adding a caveat to soften the requirement to the natural limitations coming from processing (CPU, memory) constraints. In second paragraph it says: …” There should be no limitation to the number of managers that can control an agent”. Suggest adding something like “beyond the limitations imposed by the underlying managed device(s), such as processing and memory…”.

SEH: I agree that this statement could be clarified. Our intent is to say that the DTNMA does not limit manager and agent mappings. While these mappings need to take the underlying device constraints into consideration to be useful/valid, the DTNMA is not responsible for imposing those limits.


  *   Page 12 – section 4.3. Title. Suggest changing “Intelligent” to “Adaptive”. In the era of AI, trying to avoid use of intelligent unless it directly implies AI ;-).
  *   Page 15 – Section 4.7. Title. Suggest changing “Intelligent” by “Autonomous”.

SEH: Great points – we want to be as clear as possible with our terminology choices. Version 04 of the DTNMA includes an updated Section 4 (Desirable Properties) and will update the titles we give to these properties.


  *   Page 26 – Section 7.3.2.3 Administration, Data Validators. There is a strong requirement that I am not sure is enforceable as is. It says, “DAs should ensure that externally generated data values are both verified and validated”. I am not sure that’s possible, as it totally depends on what the data value is, and what you are validating against. For example, if validation is around formats/ranges, that could be well possible, but if you try to validate the value itself, there may not be a reference to validate against. Imagine a temperature value. Suggest rephrasing, for example saying, “when possible”.

SEH: I don’t see a strong requirement here, as the DTNMA is an informational document and uses “should” rather than “must”. I do agree that this statement can benefit from additional clarification. We expect validation of the data value to be performed using the shared definition of that value, to include information such as range, length, and pattern-based constraints which we are currently adding to the ADM.


  *   Page 26 – Section 7.3.3 Managing Applications and Services. Second paragraph states, “…these applications cannot exert closed-loop control over any managed device application.” I would suggest to add “real-time” to say,”…cannot exert real-time closed-loop control”. There is always going to be options for closed-loop is just that it is going to be a (very-slow) closed-low option.

SEH: It seems that we should clarify intent in this section. The DTNMA uses open-loop control as the agent is not required (and in some cases, able to) provide a response to controls issued by a manager. Instead, policy statements provided by the managing applications and services are translated to rules that influence the agent’s behavior (ex: reaction to certain state changes for a managed application). The agent is not required to provide feedback to the manager in acknowledgement of the situation you described – real-time closed-loop control cannot be exercised in this environment.


  *   Page 30 – Section 8.2 Data Fusion. I would suggest adding a note at the end saying something like “this does not preclude sending the raw states reports to the DMs. There may be benefits to this, such as reaching a better understanding of underlying conditions to further develop autonomy algorithms”. The goal is to ensure the system also optimizes (one of the benefits of DTN) to store as much data as feasible. Data that may not be useful today but useful to science in a decade (there are many examples of that).

SEH: In either (and perhaps both) Sections 8.2 Data Fusion and 8.4 Remote Reporting, we will make sure it is clear that data fusion can produce new data, which can be included in reports, and reports can also be populated with data other than the products of data fusion (ex: state information gathered from a managed application).


  *   During the IETF115 session Ed mentioned there was a presentation/document on a proposal to bridge DTNMA to NETCONF if I remember correctly. Would appreciate if you could share this over email.

SEH: Jean Chorin’s work presented at a previous IETF: https://datatracker.ietf.org/meeting/104/materials/slides-104-dtn-ampnetconf-interop-01

[Syntax and typos]

  *   General across the document, the terms DTNMA Agent, and DTNMA Manager is used interchangeably with DA and DM respectively. It is inconsistent through the document and makes the document harder to read as DTNMA as standalone term also exists. I would suggest to (after introduction of the two terms) continue using DA and DM as it is easier to pronounce/read. For example, section 7.3.2 is titled DTNMA Agent, I suggest adding (DA).
  *   Page 10 – Section 3.2 first paragraph. Suggest to add a comma in this sentence: “When topological change impacts the semantic roles and responsibilities of nodes in the network, then local configuration…”
  *   Page 24, Section 7.3.2.1 Monitoring and Control, Rules Database. It says… Within the DTNMA these rules are the embodiment of policy expressions received from [the DM/DTNMA Manager,] managed and evaluated…
  *   Page 28, Section 7.3.4.3 Administration. In first paragraph it wrongly says “Agents in the DTNMA must perform…”. It should be “Managers (DMs) should…”. This section is for the DMs.
  *   Page 32, 8.5 Section Authorization. Last paragraph, I suggest to use more inclusive language and change whitelists, blacklists to allowlists, denylists. I have to say I don’t know what’s IETF recommendation on this.
  *   Page 41, Section 10.1 Table. DEF ([ACL], ID, EXPR), PROD (P, ID) and RPT (ID). “ID” is the only term that is not defined anywhere in the document, it took me a while to understand this is just a name…however ID typically implies some sort of identity. Suggest to either define it or to use another term.
  *   Page 45, Section 10.4. Open Loop Reporting. Paragraph before the last one. It says “ever second”, it should be “every second”.
  *   Page 48, Section 10.6 Cascading Management. It says “…Manager B sends a policy to Agent C to reports on…” it should say “to report on”…

SEH: We will reflect these changes in version 04 of the DTNMA.

--
Dr. Alberto Montilla
CEO
SPATIAM CORPORATION
Creating the Interplanetary Internet
T: [phone]
E: [e-mail]<mailto:[e-mail]>
Subscribe<https://cdn.forms-content.sg-form.com/9bdb4ae5-b676-11ec-a4f4-2a850821b4f7> to The Bundle