[dtn] AMP comment on adding tabular data schema

Brian Sipos <BSipos@rkf-eng.com> Wed, 30 March 2016 20:55 UTC

Return-Path: <BSipos@rkf-eng.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B74B12D676 for <dtn@ietfa.amsl.com>; Wed, 30 Mar 2016 13:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rkfeng.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ps063T3kXfi for <dtn@ietfa.amsl.com>; Wed, 30 Mar 2016 13:55:46 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0601.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::601]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6848412D937 for <dtn@ietf.org>; Wed, 30 Mar 2016 13:55:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rkfeng.onmicrosoft.com; s=selector1-rkfeng-com0i; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BODAIN/YgZPS/GiqZkbW8M6gBtrT4X4XEKTf5fSgCS8=; b=WYvkNKFrjP3kCI6ncN8QUVklsx04LkrG9+hAjakJiRkD8kbnNNpr5n6owwKJ3pYiNqKg2Z3tEW58yMEalbwpfmveZ/kzB5AxiBYB5FXvmT9SBEbmxuihfSMwQV4ByqYFYOhaaARgTce8TDtOyOggehfXADrTyg/uPl353NlHMkc=
Received: from DM2PR0501MB892.namprd05.prod.outlook.com (10.242.173.155) by DM2PR0501MB892.namprd05.prod.outlook.com (10.242.173.155) with Microsoft SMTP Server (TLS) id 15.1.447.15; Wed, 30 Mar 2016 20:55:28 +0000
Received: from DM2PR0501MB892.namprd05.prod.outlook.com ([10.242.173.155]) by DM2PR0501MB892.namprd05.prod.outlook.com ([10.242.173.155]) with mapi id 15.01.0447.024; Wed, 30 Mar 2016 20:55:28 +0000
From: Brian Sipos <BSipos@rkf-eng.com>
To: "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: AMP comment on adding tabular data schema
Thread-Index: AQHRisZ9ZBudXaqKFkivivFFAhBSww==
Date: Wed, 30 Mar 2016 20:55:28 +0000
Message-ID: <DM2PR0501MB8929581A00213FAA58DA90F9F980@DM2PR0501MB892.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=rkf-eng.com;
x-originating-ip: [25.162.18.4]
x-ms-office365-filtering-correlation-id: c4bcc460-0359-4919-6cfa-08d358dda01e
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB892; 5:o7/Gh51qdqIKzzwQ1hFHacFcV6JZBuaThB9H+LWGaSakI02gyKR7SY7wpUmDx6JpdZxnmBhEhb7F3L9c5bZz7lNtpAM2zeGwD15BsPo4L9tokVqbtI8GbdvIcSu/Ocej4R9kObsYKWLYrt8jRaIIoA==; 24:2MOBBF1/n8NPgKGzxWSzqxMowbLdIC9G200ixYDmWJJ/iqurXjYeU/ygoprD9DHI67hBucXROIvGMBTZ0yPqKRnnogVmz3n3rG61g+oFSRQ=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB892;
x-microsoft-antispam-prvs: <DM2PR0501MB8925CE52EB32BC06E7788DB9F980@DM2PR0501MB892.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040046)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041046)(6043046); SRVR:DM2PR0501MB892; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB892;
x-forefront-prvs: 08978A8F5C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(2501003)(86362001)(11100500001)(99286002)(3660700001)(122556002)(5002640100001)(54075001)(2906002)(5640700001)(76576001)(450100001)(106116001)(33656002)(81166005)(50986999)(66066001)(189998001)(5003600100002)(1730700002)(87936001)(229853001)(92566002)(2900100001)(54356999)(16236675004)(10400500002)(5004730100002)(1096002)(1220700001)(80792005)(19627405001)(107886002)(3280700002)(74316001)(3846002)(586003)(110136002)(102836003)(6116002)(2351001)(5008740100001)(19625215002)(77096005)(561944003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0501MB892; H:DM2PR0501MB892.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM2PR0501MB8929581A00213FAA58DA90F9F980DM2PR0501MB892na_"
MIME-Version: 1.0
X-OriginatorOrg: rkf-eng.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2016 20:55:28.5330 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4ed8b15b-911f-42bc-8524-d89148858535
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB892
Archived-At: <http://mailarchive.ietf.org/arch/msg/dtn/lfU30ZlfkIe0t_-IjaAAgbGedlM>
Subject: [dtn] AMP comment on adding tabular data schema
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2016 20:55:49 -0000

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.