Subject: Re: [dtn-interest] New Network Management Specs

From: Brian Sipos <[email-masked]>
Date: Tue, 9 Feb 2016 17:43:19 +0000

Edward,
I'm putting my comments in here just so they make it back to the DTN-interest list as well as yourself.
My background in remote management is mostly in SNMP, with some dabbling in NETCONF, so my views will be colored by those protocols.

Some comments on AMP:
1. There seems to be no way to correlate a specific report instance with whatever trigger (instance) caused it. In SNMP and NETCONF (RPCs) there is a mechanism for the manager to assign a correlation ID to individual request messages and the agent will then use the same correlation ID in response messages. My concern is that without this mechaism, a manager sending controls "Update TYPE item A", "Update TYPE item B", "Update TYPE item A" and receiving reports "Succeeded TYPE item B", "Failed TYPE item A", "Succeeded TYPE item A" but there is no way to know which update of A succeeded and which failed. Timing can imply one or the other, but DTN environment is particularly decoupled from timing and because reports can be bundled there is no generic way to associate report with control.
Would it be reasonable to add some kind of correlation ID (SDNV?) to commands and reports, with ID zero indicating no-correlation (or similar)? This way always using zero correlation is the same behavior as current but there is an application-independent way to correlate reports with original commands.

2. It appears that the AMP mechanism for handling application-defined data types is to encode in AMP as BLOB and rely on the endpoints to perform unique-per-MID data handling. This certainly saves in on-the-wire typing data, but pushes more application-specific data handling to the ADM specifications (not a bad thing). Is BLOB intended as a catch-all for application-specific data? It may be useful to state this explicitly in the AMP spec. Do you see any benefit to having vendor-specific type-tags (as some protocols do) rather than relying on MID-specific processing? SNMP in particular does get messy when custom types start being used.

3. It appears that the expected way to handle lists- or sets-of-items is to provide an application-specific identifier to each item and (as it is done in the Agent ADM) add/modify/retrieve/delete by those IDs. I suppose that this is the most-generic behavior to defer particular list semantics to the application definition. It may be useful to state this explicitly in the AMP RFC rather than need to infer from the various ADM examples, if this is in fact the "proper" behavior.

4. If I wanted an ADM with a relatively simple get/set pair of commands, it seems like the get command would need to be parameterized by the MID of the item to fetch and would respond with a report containing a MID, possibly a type BLOB, and value BLOB then it would be up to the application to determine the proper coding of the value BLOB based on MID. Likewise a set command would be parameterized by a MID and a BLOB value, where again the application must rely on the MID schema to determine the BLOB contents. Does this sound correct?
It seems like having a formal ADM specification would go a long way to helping a AMP manager program to properly encode/decode MID-specific BLOB contents. Although I understand that it's a whole separate rabbit hole in trying to formally specify thing "all the way down" and there will need to be some amount of application-specific behavior.

Thank you for any feedback,
Brian S.

________________________________________
From: dtn-interest <[email-masked]> on behalf of Birrane, Edward J. <[email-masked]>
Sent: Monday, August 24, 2015 10:28
To: [email-masked]
Subject: [dtn-interest] New Network Management Specs

A few changes to the DTNMP, for those following it:

- The "Delay-Tolerant Network Management Protocol" (DTNMP) is renamed the "Asynchronous Management Protocol" (AMP).

- Three new internet-drafts have been submitted, as follows.

1. An Asynchronous Management Architecture (AMA), https://tools.ietf.org/html/draft-birrane-dtn-ama-01, has been published which describes the desirable properties, roles/responsibilities, control flow, logical data model, etc... for the proposed asynchronous management architecture.

2. An Asynchronous Management Protocol (AMP), https://tools.ietf.org/html/draft-birrane-dtn-amp-01, has been published which describes a data model and functional specification to communicate messages in an AMA.

3. An Asynchronous Management Agent Application Data Model (Agent ADM), https://tools.ietf.org/html/draft-birrane-dtn-adm-agent-00, has been published which describes how to manage a managed device in the AMA using the AMP.

- The specs are associated with the DTNWG for now - based on conversations with the DTNWG chairs it seemed like that was a reasonable place to park these internet-drafts for the time being.

Comments welcome!

-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

_______________________________________________
dtn-interest mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest