[Sis-dtn] FW: [EXT] [dtn] review of draft-ietf-dtn-dtnma-05

[Birrane, Edward J.]

FYI

Edward J. Birrane, III, Ph.D. (he/him/his)
Chief Engineer, Space Constellation Networking
Supervisor, Embedded Applications Group 
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (C) 443-690-8272

-----Original Message-----
From: dtn <dtn-bounces at ietf.org> On Behalf Of Jürgen Schönwälder
Sent: Monday, June 26, 2023 3:42 AM
To: dtn at ietf.org
Cc: Rob Wilton (rwilton) <rwilton at cisco.com>
Subject: [EXT] [dtn] review of draft-ietf-dtn-dtnma-05

APL external email warning: Verify sender dtn-bounces at ietf.org before clicking links or attachments 

Hi,

Rob Wilton asked me to review draft-ietf-dtn-dtnma-05. First of all, the document is very well written and easy to read. I am not sure whether the NMRG is aware of this work, perhaps this is another good place to ask for reviews and feedback on this work since the NMRG did discuss autonomic management quite a bit. There are likely some more people on the NMRG list recalling that policy-based management was a big thing in the late 1990s when people believed that distributing management logic is the way to go, before we got a large push for centralization at the beginning of this century.

* Section 4

  - It remains somewhat opaque what 'inclusion' means in Section 4.2.
    Perhaps this is on purpose but inclusion comes in many different
    forms and flavors. And perhaps you really mean reuse and not
    inclusion?

* Section 5

  - Consider referencing RFC 3410, which is the general reference for
    the SNMPv3 framework. RFC 3410 also details some differences
    between the different versions.

  - We generally talk about 'event notifications' in later versions of
    SNMP, traps are a specific message format to convey an event
    notification, informs are another message format. The purpose of
    both is to notify a manager that an event has happened..

  - SNMP originally used trap-directed polling; the idea simply was to
    be able to react to events quickly while polling relatively
    infrequently. SNMP notifications are not really about autonomy,
    they are used to decrease reaction time: You poll every five or
    ten minutes but the device sends you a notification immediately if
    a link goes down.

  - The DISMAN WG did standardize MIB modules for more autonomous
    behaviour of SNMP agents (the expression MIB, the scriting MIB,
    the scheduling MIB) but they were not widely deployed. Worth
    noting here is that autonomous functions were considered to be a
    data model writing exercise and not a protocol mechanisms exercise
    (Back then, adding verbs to the protocol was considered really
    bad.)

  - YANG is just called YANG (don't try to expand it). Any particular
    reason why you do not cite YANG 1.1 (RFC 7950), which largely has
    replaced YANG 1?

  - The modeling of operational state was a bit simplistic in the
    early years. Perhaps consider mentioning RFC 8342. Some of the
    distinctions made there (e.g., the difference between configured
    state and applied configuration state) has already been an issue
    in the SNMP world and perhaps this may be relevant for a DTMNA
    world as well.

  - Work on policy-based management has a 20+ years history. For
    example, using event-condition-action rules to offload control has
    been studied extensively, including things like conflict detection
    or stability analysis. There was an entire series of policy-based
    management workshops back then. Another direction was to be less
    restrictive on the format (i.e., a specific rule language) but
    instead allow managers to send 'management scripts' that are then
    executed locally. Sandboxing was an issue back then and it still
    is. But meanwhile we are all excited again about eBPF (pushing
    byte code into the kernel) so perhaps we get to this "lets simply
    send some control logic as code" approach again.

* Section 7

  - It is not clear what command-based means. Some may consider SNMP
    variable-based, CMIP object-based, CLIs command-based, and YANG
    document-based. Many early policy-based network management systems
    were rule-based. There were also some experiments with code-based
    approaches, where some form of binary executable code was pushed
    around.

  - Are directives the same as commands?

  - Why is the Autonomy Engine not simply called a Policy Execution
    Engine?  More importantly, is the DM configuring the Autonomy
    Engine or just the Rules Database? If so, why is there a
    conceptual difference between configuring the Rules Database and
    the Autonomy Engine?

  - With multiple managers, how are conflicts resolved? Or how is
    stability achieved? What if A says every 2 seconds to up and B
    says every 3 seconds go down?

  - Why does DTMA not aim to standardize specific transports or
    encoding of policies (autonomy model instances)? I would have
    expected that there is a standard exchange format over BP7 at
    least.

* Section 8

  - Can the policy rules access fused data, i.e., can predicates of
    rules refer to fused data? My reading of section 10 says that the
    answer is likely yes but perhaps make this clearer here.

* Section 9

  - In the history of policy models, event-condition-action rules were
    often used since in many situations you want to react to events:

    ON <event> IF <condition> THEN <action>

    Sure, you can somehow make events part of your 'stimulus' (the
    predicate) but this often makes things more complicated to
    understand. Also note that events may need to be created from
    monitoring data (or data fusion in your architecture). So why do
    you prefer the IF <stimulus> THEN <response> approach? (Note that
    <event> did often include time triggered events, i.e., timers
    throw events that you can bind a rule to.)

  - Large rule sets have been found difficult to understand and
    debug. How are you going to deal with this? How do you make them
    conflict free?  How do you avoid oscillating effects? What do you
    mean by deterministic if stimuly (events and conditions) can
    depend on dynamically acquired state? If you want to be able to
    understand what happened after the fact, you likely need a
    reliable log much more than anything else.

  - It feels like section 9 is going into details that do not belong
    into an architecture document (e.g., sections 9.3 and 9.4).

* References

  - Relevant work (perhaps worth reading and considering):

    - A. Westerinen et. al: Terminology for Policy-Based
      Management. RFC 3198, November 2001

    - R. Boutaba, I. Aib: Policy-Based Management: A Historical
      Perspective. Journal of Network and Systems Management. Vol. 15,
      No. 4, pp. 447-480, Springer, December 2007

* Editorial

  - s/Oner/One/

  - s/any changes the require/any changes that require/

  - s/controls a are/controls are/

-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://constructor.university/>

_______________________________________________
dtn mailing list
dtn at ietf.org
https://www.ietf.org/mailman/listinfo/dtn