Re: [dtn] AMP comment on adding tabular data schema

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

Brian,


 I agree. The logical table structure is very useful, can be accomodated with existing AMP structures, and guidance would be a big help to ADM developers.


  We should add a section section 6 with a subsection on Guidelines for ADM developers and place this recommendation (and others) there.


-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 <[e-mail]> on behalf of Brian Sipos <[e-mail]>
Sent: Wednesday, March 30, 2016 4:55 PM
To: [e-mail]
Subject: [dtn] AMP comment on adding tabular data schema



This is a comment against "draft-birrane-dtn-amp-02".

I think it would be very useful for both AMP and the ADM YANG profile to define semantics for encoding lists/tables of values. The encoding syntax of this would require no changes to AMP, as a table-of-rows can be encoded with a DC-type structure and a row-of-values can be encoded as a TDC-type structure. And on the ADM side, the MID "parameter" values can easily be used to support row identifiers (although it is currently forbidden for "primitve" OIDs).

Allowing specifying a tabular form within in the OID tree is very powerful in my view, and needing to have each application define the semantics of each data table is a large burden to the ADM writers (and users). This would also allow AMP to more closely align with YANG assumptions of encoding/transport protocol. My proposal would still require the ADM to define semantics of modifying table contents (add/update/remove/sort/etc.) but at least the table definition itself (and reports containing table rows) would be protocol-standard.

An notional example of this method follows:

I am using the current NETCONF-style definitions of list/table, which is quite a bit simpler than SNMP-style definitions. The MID-style of specifying objects is very powerful with the ability to parameterize, which this takes advantage of.
For a concrete example, in text form:
A "list" named "Table" is defined with OID [N].1 it has "column" primitives named "Ident", type INT, OID [N].1.0, "ValueA", type VAST, OID [N].1.2, and "ValueB", type STR, OID [N].1.3. The Table identifies "Ident" as its key column.
The table contents are logically two rows:
    1,3,"hello"
    5,-8,"world"

There are three ways to access this logical list-of-rows, which are:
- Fetch a report with only the non-parameterized "Table" OID [N].1. This results a TDC with packed row values of (INT) 1, (VAST) 3, (STR) "hello", (INT) 5, (VAST) -8, (STR) "world". This is a kind of discovery or full-table report.
- Fetch a report with OID [N].1 parameterized (on its key column) by (INT) 5. This results in a TDC with single-row values of (INT) 5, (VAST) -8, (STR) "world". The same contents as one row from above, but the parameter limits to only the desired row.
- Fetch a report with OID [N].1.2 parameterized (on the table key column) by (INT) 1. This results in a single value (VAST) 3. This method is identical to how some of the values in current draft-birrane-dtn-adm-bp-00 behave. This allows reporting on arbitrary single-values.