Re: [Int-dir] [EXT] INTDIR Review of draft-ietf-dtn-dtnma-10.txt

[Donald Eastlake <[e-mail]>]

Hi Ed,

See below.

On Thu, Feb 15, 2024 at 1:19 AM Birrane, Edward J.
<[e-mail]> wrote:
>
> Donald,
>
>   Thank you for your review of the dtnma-10 document.  I have posted
> responses and recommendations in-line below, and have enumerated
> them as EJB_D# for discusses) and EJB_C# (for others) to help with
> referencing.
>   Please let me know if the recommendations below would address your
> discusses and comments.

OK.

> -Ed
>
> ---
> Edward J. Birrane, III, Ph.D. (he/him/his)
> Chief Engineer, Space Networking
> Space Systems Implementation Branch
> Space Exploration Sector
> Johns Hopkins Applied Physics Laboratory
> (W) 443-778-7423 / (F) 443-228-3839
>
> > 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.
>
> EJB_D1:  The document provides some general statements that managed
> devices must "perform their own error discover and mitigation"
> (Section 1.0), that DA's are responsible for "error handling"
> (Section 2.0) and must "handle critical events (such as errors)"
> (Section 7.3.2.2).  The specific case of a rule response failing is
> discussed in Section 9.5, which says "The success of failure of a
> control may be handled locally by the agent autonomy engine."
>
> EJB_D1: I agree that an explicit statement to consider a "safe
> state" and/or "control-specific recovery" could easily by added as
> clarifying text as examples of how the agent autonomy engine might
> handle a control failure.  So, recommend adding a sentence to that
> effect to Section 9.5 as part of the existing discussion of handling
> control failures.  Other types of failures of the DA, I think, are
> covered by the more generic error handling wording mentioned above.

I agree that Section 9 is a reasonable place to cover this. Possibly
just adding two or three sentences... I would like to see the following
three things touched on:

1. The importance of considering local error handling at the Agent due
to the possible infrequence of Agent-Manager connectivity. (Mentioning
error handling just parenthetically in passing in the Data Fusion
section (7.3.2.2) does not seem adequate.)

2. In connection with 1 above, the occurrence of errors should be a
trigger or accessible via a predicate or something so the response to
the error can be programmed.

3. Mention the advisability of having a "safe state" for the DTNMA or
parts thereof that can be installed on certain errors.

> > 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?
>
> EJB_D2: Agree that the implementation of such bulk updates is an
> important consideration. The existing text in that section does
> discuss the need to consider pre-conditions prior to attempting
> such and update. Recommend adding a parenthetical to that sentence
> that a good example of a pre-condition to be checked is whether
> some other update is already occurring on the device.

OK.

> EJB_D2: Also agree that rollback is an important function, and I
> think would be covered by the recommendations in EJB_D1.

OK if this is also covered in changes stemming from EJV_D1 above.


> > 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".
>
> EJB_C1: As this is an informational document, we would not want this
> to be the place to define normative requirements. We do agree that
> there is good detail in this document to help with a subsequent
> requirements document.

It is a bit fuzzy what the boundary is between a "normative
requirement" and a restriction that the architecture imposes...

> > 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".
>
> EJB_C2: Recommend a review of the use of lowercase "must" and reword
> using alternatives in cases where "must" could imply specific
> normative behaviors from an informational document (specifically in
> sections 7,8,9).  However, many uses of "must" describe consequences
> of operating environments or otherwise logical processing outcomes,
> which would be consistent with an informational document and we
> would recommend not changing wording in those cases.

OK.

> > 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.
>
> EJB_C3: Agree that the term "poor choice" is a poor
> choice. Recommend replacing that term with "unsuitable for operating
> in...".  Otherwise, believe that a review of "must" as proposed in
> EJB_C2 would address other concerns here.

OK.

> > 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".
>
> EJB_C4: There is another comment from another reviewer which
> suggests replacing the term "closed-loop" with "system-in-the-loop
> synchronous function" and believe that applying that to this section
> would help explain the intent better. Agreed that there are
> relationships between commands and responses, but that does not need
> to be a 1-1 relationship - a single response can be a report
> capturing the output or effects of multiple commands. For example, a
> managed device might execute multiple (dozens) of commands and
> provide a single report back, which is the number of commands
> successfully executed.

OK as long as there is some re-wording that clarifies that responses
and commands are not completely independent.

> > In Section 7.3.4, Agent Mappings, it says "only appropriate controls are sent
> > to a DA". Should "controls" be "commands" or "control policies?
>
> EJB_C5: The DTNMA, in section 2, defines the word
> Control.  Recommend reviewing the use of the term "control" in the
> document to see where we should use "Control" instead of
> "control".  Recommend correcting this instance of Section 7.3.4 in
> particular to say "only appropriate Controls..."

OK.

> > 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.
>
> EJB_C6: Agreed that this is confusing.  Recommend removing the two
> uses of the word mnemonic in Section 10. It is sufficient to say
> that Section 10 references the autonomy model from 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".
>
> EJB_C7: Agreed. The intent here is "add".  Recommend changing to "add".
>
> > Although it is pretty obvious that CTRL stands for Control, this is never
> > defined.
>
> EJB_C8: Agreed, and good catch. This is leftover terminology and
> needs to be corrected to "Control".
>
> > Section 5.3: "exciting" sounds like marketing. Suggesting deleting that
> > adjective.
>
> EJB_C9: Agreed. Good catch. Recommend removing this word.
>
> > 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.
>
> EJB_C10: Agreed that the source of EDD1 should be in this
> illustration. Recommend, instead, adding a PROD(1s, EDD1) and a
> RPT(EDD1) between the DTNMA Manager B and DTNMA Agent B.

OK.

> > 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."
>
> EJB_C11: Agreed. Recommend changing the text as suggested.

Thanks for all the Agreed's above.

> > 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.
>
> EJB_C12: Many notes, through WG participation, were added to
> emphasize perspectives or points of view. Since this is an
> informational document we felt that these perspectives helped
> explain some thinking behind certain concepts. Recommend keeping
> them.

I continue to think there are an excessive number of them so they lose
their impact and don't really do anything but this is just a minor nit
so I'm ok with you keeping them if you like them.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]