Re: [dtn] Comments on AMP draft 03

["Birrane, Edward J." <[e-mail]>]

Brian,

  There were a few things that did not make it into the -03 which will be presented as future work next week and targeted for the -04 version to be released in around September timeframe. They include:


1.       TDCs for column identifiers. Working through some edge cases now on implications for Agent ADM.

2.       Access control lists, ACK/NACK, and control status (Jeremy is working this section now and has a draft)

3.       Transition to CBOR. And yes, help would be appreciated here.

  UNK is shorthand for Unknown and should be clarified.

  A few other thoughts/items of future work:

OID introspection
---------------
  Currently AMP tries not to infer too much meaning in the OID representation. It is an open topic on whether and how AMP Agents need to build internal representations of OID trees. For example, if/when we add introspection to the Agent ADM is it by binary match or by concept of sub-tree?

Times in Controls
---------------
  The time to run a command was preserved because of macros. If a TRL executes a macro, that macro *could* kick off its own TRLs to run individual commands, but that is a heavy-weight way to approach this functionality. Also, if an implementation needs to abort a macro, going back and trying to clean up any TRLs generated by the Macro so that they do not fire later would be a headache.

Macros
----------------
  Enhanced macro support is being considered, including operations for pause and wait on condition. This may define controls that may only appear inside a macro. Also, additional descriptions of macro error recovery - what happens when you are half-way through an executing macro and a command fails? Does AMP need a transaction model, or is recovery left to the user? Are other protocol items needed to support the user such as a pre-defined recovery macro?

Guidance on TABLE usage (and ADM authorship in general)
----------------
  A review of ADMs will be undertaken to remove controls that currently just list data and replace them with tables. I have drafted some text on when an ADM should use a control, simple data item, or table. Core ADMs will be made consistent with that guidance.

Encodings
----------------
  My opinion is that AMP messages should have a single binary representation. The DTNWG is going a different path with BP, but AMP is "just" a payload in a BP or IP (or other) PDU so should not be affected by alternate encoding schemes.  I wonder if there will be a similar request to support alternate encodings for AMP messages.

ADMs
----------------
  In addition to a refactoring of existing ADMs to migrate certain data and controls to tables, the Agent ADM will have new controls for introspection and to handle/query tables.  This will require some mechanism (OP?) for typed pattern matching.

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839


From: dtn [mailto:[e-mail]] On Behalf Of Brian Sipos
Sent: Tuesday, July 12, 2016 9:07 AM
To: [e-mail]
Subject: [dtn] Comments on AMP draft 03


I'm glad to see progress on the AMP specification, and have a few comments after reading through changes to version 03.



In Section 3.2.4 "Table", I'm happy that a tabular structure made it in the spec. My only comment is on the column identifier: I would very much prefer if this were a TDC right away, with options for types:

 1. STR for the kind of ad-hoc table represented here, where the table does not conform to an ADM schema.

 2. MID for a table containing data defined by an ADM schema. Each column in the ADM definition would have its own OID represented here.

 3. INT to represent a "sub-OID" which is a single OID component representing the column's OID subordinate to the parent table OID. This is an encoding optimization, and simply represents a full OID in a compressed form. If this is too confusing, I would leave it out. A compressed-form MID would have much of the same benefit.


In Section 5.1 requirements, must an AMP Agent fail if a "type promotion" causes overflow or similar data loss? How is that failure indicated to a Manager?

In Figure 25 there is reference to a type "UNK" but this type name does not come up anywhere else in the document. This seems to be a left-behind artifact from earlier typing scheme.



In section 7.5 "Perform Control" there is a "Start" time which we had discussed earlier as possibly deprecating in favor of using a TRL if delayed control is desired. Is this "Start" time indented to be kept in? If it were to be removed, the control would simply be run at the time of received message processing.



My last meta-comment on the AMP is related to encoding an possible transition to CBOR. If this is something which is going to happen anyway, then I would really rather avoid having two separate AMP encodings and simply migrate the current spec to CBOR. As painful as that may be near-term, I think it will side-step most of the issues that I have commented on regarding AMP typing/encoding. I would be able to assist any CBOR migration if wanted or needed.

Thanks.