Re: [dtn] [EXT] Roman Danyliw's Discuss on draft-ietf-dtn-dtnma-10: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Ed!

Thanks for the revised -11 and the detailed explanations below.  I've reissued my ballot clearing all blocking feedback.  I believe that a bit more clarity in the behaviors described in Section 4.7 would be beneficial, using your clarification in the thread below as a basis.  However, I leave the need for that remaining polish to the WG.

Roman

> -----Original Message-----
> From: Birrane, Edward J. <[e-mail]>
> Sent: Tuesday, February 13, 2024 10:27 PM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: [EXT] Roman Danyliw's Discuss on draft-ietf-dtn-dtnma-10: (with
> DISCUSS and COMMENT)
> 
> Warning: External Sender - do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> 
> Roman,
> 
>   Thank you for the review of this document.  I have included
> replies/recommendations in the text below.   To help with the discussion, I
> have enumerated discuss points prefaced with EJB_D# and comments prefaced
> with EJB_C#.
> 
>   Please let me know if the recommended actions described below would
> address the discusses and comments from your review.
> 
> -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
> 
> 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > ** The text would benefit from a refinement of the explanation of the
> > security boundary of the DTNMA.
> >
> > Consider the following statements:
> > (a) Section 1.1 says “Network features such as naming, addressing,
> > routing, and security are out of scope of the DTNMA.  It is presumed
> > that any operational network communicating DTNMA messages would
> > implement these services for any payloads carried by that network.”
> >
> > (b) Section 4.7 says “The DTNMA does not require a specific underlying
> > transport protocol, network infrastructure, or network services.
> > Therefore, mechanisms for authentication, authorization, and
> > accounting must be present in
> > a       standard way at DAs and DMs to provide these functions if the
> > underlying network does not.”
> >
> > (c) Section 7.3.2.3 says “DAs should ensure, when possible, that
> > externally generated data values have the proper syntax (e.g., data
> > type and ranges) and any required integrity and confidentiality.
> >
> > -- Statement-(a) seems to rule out elements of security as being part
> > of DTNMA.
> >  However, the text subsequently makes various statements about DTNMA
> > ensuring security properties (e.g., statement-(b) and statement-(c))
> 
> EJB_D1: Agree that discussion on security boundaries should be refined.  We
> recommend correcting the text as follows:  Statement-(a) should be updated to
> say "communications security" instead of "security" to emphasize that this
> statement is related to comsec considerations such as those provided by a
> transport protocol.  Statement-(b) should be updated to refer only to
> authorization and accounting. Statement-(c) should be refined to remove
> reference to integrity and confidentiality as it is already covered in prior
> statements.
> 
> EJB_D1: Generally, to make a pass through the document to ensure that any
> specific referenced to authentication, integrity, security are unambiguously in
> agreement with Statement-(a).
> 
> 
> > -- In clarifying this scope, can the distinction between the DTNMA and
> > the “operational network communicating DTNMA” or a “DTNMA
> > implementation” be explained?  Is the operational network part of the
> > architecture? Is an implementation an instantiation of the
> > architecture?  I ask because the following statements also seem to
> > discuss security properties:
> >
> > Section 8.5 says “It is expected that transport protocols used in any
> > DTNMA implementation support security services such as integrity and
> > confidentiality.”
> >
> > Section 12 says “As such, security at the transport layer is expected to
> > address the questions of authentication, integrity, and   confidentiality.”
> 
> 
> EJB_D2: Agree that these statements introduce scope ambiguity as worded.
> Recommend correcting the text by removing these statements as they are
> restatements of not-ambiguous information already present elsewhere in the
> document. Generally, these statements do not intend to alter the meaning of
> the statements highlighted in EJB_D1.
> 
> 
> 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > ** Section 1.
> >       |  NOTE: These challenges may be caused by physical impairments
> >       |  such as long signal propagation and frequent link disruption,
> >       |  or by other factors such as quality-of-service prioritization,
> >       |  service-level agreements, and other consequences of traffic
> >       |  management and scheduling.
> >
> > Could these challenges be caused by an active attacker too?
> 
> EJB_C1: Agree that these challenges can also be caused by an attacker (as well
> as misconfiguration). Recommend updating the text to add those to the list in
> this aside.
> 
> 
> > ** Section 1.* What is intent on describing the relationship between
> > DTNA and BP?  There seem to be multiple slightly different statements.
> > Specifically:
> >
> > -- Section 1.0 says “However, the DTNMA should operate in any
> > environment in which the Bundle Protocol (BPv7) [RFC9171] is
> > deployed.”
> >
> > -- Section 1.1 says “The fact that the DTNMA must operate in any
> > environment that deploys BP does not mean that the DTNMA requires the
> > use of BP to operate.”
> >
> > --  Section 4.1 says “The DTNMA must run in every environment in which
> > BP bundles may be used, even though the DTNMA does not require the use
> > of BP for its transport.”
> >
> > Is it intentional for the first statement to be weaker statement than
> > the second and third.
> 
> 
> EJB_C2: Agree that the terminology here needs to be clarified. Section 1.0 is
> intended to be the strongest statement of the three. Recommend changing the
> wording in Section 1.0 to "the DTNMA needs to be able to operate...".
> Recommend changing the wording of both Sections 1.1 and 4.1 to replace the
> word "must" with the word "can".  As an informational document there is no
> intent to use (or imply) normative language here.
> 
> > ** Section 2.  Editorial. Consider harmonizing the implicit definition
> > of DTN management from Section 1 with the one used here.
> >
> > -- Section 1 says “Device management in these environments must occur
> > without human interactivity, without system-in-the-loop synchronous
> > function, and without requiring a synchronous underlying transport
> > layer.”
> >
> > -- Section 2 (here) says “DTN Management: Management that does not
> > depend on stateful connections, timely data exchange of management
> > messages, or closed-loop control.”
> >
> > e.g., “system-in-the-loop synchronous function” vs. “closed-loop control”
> 
> EJB_C3: Agreed.  Recommend changing the text in Section 2 to adopt the
> wording from Section 1.
> 
> 
> > ** Section 2.
> >    *  Data Report Schemas: Named, ordered collection of data names that
> >       represent the schema of a Data Report.
> >
> > What are “data names”?  I would have expected a data schema to define
> > the format and semantics of the fields of a data report.
> 
> EJB_C4: Agree that the term "data names" is ambiguous and recommend
> correcting the text to say "data elements" instead.
> 
> 
> > ** Section 3.1
> >    *  The existence of external infrastructure, software, systems, or
> >       processes such as a Domain Name Service (DNS) or a Certificate
> >       Authority (CA) cannot be guaranteed.
> >
> > What is “external software”?
> 
> EJB_C5: Agreed that this is confusing.  This is supposed to refer to external
> services. Recommend correcting the text to say "services" instead of
> "software".
> 
> > ** Section 4.1.
> >       |  NOTE: The DTNMA must run in every environment in which BP
> >       |  bundles may be used, even though the DTNMA does not require the
> >       |  use of BP for its transport.
> >
> > I don’t understand the constraint/requirement this statement is making.
> > What
> > governs where “BP may used”?  Couldn’t that be “everywhere” meaning
> > the DTNMA needs to also run “everywhere”?
> 
> EJB_C6: Agree, but believe this would be addressed with the recommended
> corrections related to the DISCUSSes.
> 
> 
> > ** Section 4.4.  This section seems very vague to the degree of not
> > provide actionable design guidance. How “efficient” is an encoding
> > seems light it might depend entirely on the deployment environment.
> > It also appears that that there are assumption being made about
> > hardware capabilities (or lack thereof) when discussion the complexity
> > of encoding or use of compression.
> 
> EJB_C7: We believe that there is value in some discussion relating to these
> concerns even absent specific design guidance, which we would expect to be
> represented in subsequent, non-informational documents. Recommend keeping
> this section.
> 
> > ** Section 4.4
> >    There is no advantage to minimizing node processing time in a
> >    challenged network.
> >
> > Is there sometimes a relationship between processing time and power use?
> > Isn’t
> > power usage relevant in challenged networked?
> 
> EJB_C8: Agree that this sentiment is implementation and system specific, and
> not relevant to the DTNMA itself. Recommend updating the text to remove this
> paragraph.
> 
> > ** Section 4.4
> >       Design strategies for
> >       |  compact encodings involve using structured data instead of
> >       |  large hash values, reusable, hierarchical data models, and
> >       |  exploiting common structures in data models.
> >
> > Doesn’t the advice here to not use “large hash values, reusable
> > hierarchical data models …” conflict with the guidance in Section 4.2
> > (“Data models in the DTNMA should allow for the construction of both
> > cohesive models and hierarchically related models.”)
> 
> EJB_C9: The intent of this note is to encourage structured data, hierarchical
> data models, and common structures and to discourage (only) very large hash
> values. This is not clear from the use of commas in this sentence. Recommend
> clarifying the meaning of this note with less ambiguous language.
> 
> > ** Section 4.5
> >
> >    Elements within the DTNMA should be uniquely identifiable so that
> >    they can be individually manipulated.
> >
> > -- What is the relationship between then “element” defined here and a
> > “managed device” used in previous definitions?
> >
> > -- Didn’t Section 1.1 says “Network features such as naming ... are
> > out of scope of the DTNMA.”
> 
> EJB_C10: Agree that the use of the term "element" here is ambiguous. In this
> context element refers to a data element. Recommend correcting the text to
> say "Data elements..." instead of "Elements..."   Also recommend a pass
> through the document to clarify any other ambiguous uses of the term
> "element".
> 
> 
> > ** Section 4.5.  Per the algorithm on approximating an associative
> > array lookup, I would have benefit from more text that explained why a
> > universal ID would have helped the situation.
> 
> EJB_C11: Agreed that additional text can be added to clarify this example, and
> recommend adding that text to the example.
> 
> > ** Section 4.6.  Is the run-time data definition just a design
> > consideration of the schemas being used?
> 
> EJB_C12: This text is not meant to imply switching amongst schemas during
> runtime. The goal here is to dynamically add data elements to the local runtime
> schemas as needed - such as the definition of new counters, new reports, or
> new rules. Recommend adding a sentence at the start of this section to clarify.
> Recommend no change to this section.
> 
> > ** Section 4.7.  I had trouble understanding the thesis of this
> > section.  Can the difference between “stand-alone”, “deterministic” and
> “engine-based”
> > behavior be clarified?  For example, what is the difference between
> > the engine-based behavior having “configurable behavior” without
> > mobile code and stand-along operation having “pre-configuration
> > [which] allows DAs to operate without regular contact with other
> > nodes?
> 
> EJC_C13: "Stand-alone", "deterministic" and "engine-based" are intended to
> describe complementary aspects of DA functions, so there may be some
> overlap in the descriptions because they work together. For example, "stand-
> alone operation" with pre-configuration can be achieved with engine-based
> behavior when the pre-configuration is a pre-configuration of the engine.
> Recommend no change to this section.
> 
> 
> > ** Section 4.7
> >
> >       |  NOTE: The deterministic automation of the DTNMA can monitor and
> >       |  control AI/ML management applications on a managed device.
> >       |  Using multiple levels of autonomy is a well-known method to
> >       |  balance the flexibility of a highly autonomous system with the
> >       |  reduced risk of a deterministic system.
> >
> > I can’t tell if this is an aspiration or required design property of a system.
> > Can such confidence be asserted generically (i.e., The deterministic
> > automation of the DTNMA can monitor and control AI/ML management
> > applications on a managed device)?  I recommend removing this aside.
> 
> EJB_C14: This is not intended to be a required design property of the system,
> and only an observation. Since this is an aside and not necessary for DTNMA in
> general or the section in particular, recommend removing this aside.
> 
> > ** Section 7.3.2.2.
> >       The
> >       generation of a report is independent of whether there exists
> >       any connectivity between a DA and a DM.  It is assumed that
> >       reports are queued on an agent pending transmit
> >       opportunities.
> >
> > What part of the DA is responsible for sending the Reports?
> >
> > I observer that Section 7.3.4.2 describing the DM has: “Report
> > Collectors DMs receive reports from DAs in an asynchronous manner.
> > Should there be symmetry?
> 
> EJB_C15: The generation of a report (in this Report Generation section) occurs
> independent of whether there exists any connectivity between a DA and a DM.
> It is assumed that the reports, once generated, are provided to some transport
> function. The use of the term "send" for reports that might be buffered/stored
> was avoided so as to not imply immediate transmission. Recommend clarifying
> that the "Report Generator" function generates reports and provides them to
> whatever local mechanism takes responsibility for their eventual transmission.
> 
> > ** Section 7.3.2.
> >        DAs should
> >        ensure, when possible, that externally generated data values
> >        have the proper syntax (e.g., data type and ranges) and any
> >        required integrity and confidentiality.
> >
> > -- Is this assurance of integrity and confidentiality before it is
> > pushed to the DM? -- Are there authenticity checks?
> 
> EJB_C16: The use of the term integrity and confidentiality here is not needed.
> Recommend removing these terms to avoid confusion and updating the
> sentence to read "..have the proper syntax and semantic constraints (e.g., data
> type and ranges) and any required authorization."
> 
> > ** Section 8.5
> >    It is expected that
> >    transport protocols used in any DTNMA implementation support security
> >    services such as integrity and confidentiality.
> >
> > Is authenticity a relevant security property?  I ask because Section
> > 12 says “… security at the transport layer is expected to address the
> > questions of authentication, integrity, and confidentiality.”?
> 
> EJB_C17: Agreed. Recommend updating section 8.5 to match section 12.
> 
> > ** Section 9.1
> >
> >    Determinism allows for the forensic reconstruction of device behavior
> >    as part of debugging or recovery efforts.
> >
> > Isn’t determinism also important to ensure predictable behavior?
> 
> EJB_C18: Agreed. Recommend updating the text to list this as another benefit.
> 
> > ** Section 9.1
> >
> >       |  NOTE: The use of predicate logic and a stimulus-response system
> >       |  does not conflict with the use of higher-level autonomous
> >       |  function or the incorporation of machine learning.  The DTNMA
> >       |  recommended autonomy model allows for the use of higher levels
> >       |  of autonomous function as moderated and controlled by a more
> >       |  deterministic base autonomy system.
> >
> > …
> >    The DTNMA autonomy model is a rule-based model in which individual
> >    rules associate a pre-identified stimulus with a pre-configured
> >    response to that stimulus.
> >
> > I am having trouble following what multi-tiered autonomy system is
> > being referenced here and where that fits in the DTNMA.  Is that a DA or a
> DM?
> > The
> > text below the notes seems to make a statement that the DTNMA autonomy
> > model is rule based.
> 
> EJB_C19: The DTNMA may be used to manage both applications and network
> services on a managed device (from the introduction). This note is meant to
> address that the use of other autonomy models (outside of the DTNMA) can
> also be used for the management of application and network services on a
> managed device. And that the use of such other autonomy models is not,
> necessarily, a conflict with the rule-based autonomy provided by the DTNMA.
> Recommend clarifying this point in the aside.
> 
> > ** Section 12.
> >
> > -- Would the data validation role played by the DA (Section 7.3.2.3)
> > be critical to mention here as this would drive action in the “agent
> > autonomy engine”?
> 
> EJB_C20: Agree (and this might be resolved by EJB_C16). Recommend updating
> this text to add that data validation is important here.
> 
> > -- Section 3.2.1 mentions “support a many-to-many association amongst
> > managing and managed device”.  Is that handled by pre-provisioning or
> > is there some kind of authorization and authentication model where a
> > managed device can always determine who is authorized to manage it?
> 
> EJB_C21: This informational document does not provide a mechanism for this.
> Section 7.3.2.2. does mention caveats for multiple managers, and section 8.5
> discusses an authorization service but a specific mechanism is not provided.