[icnrg] FLIC annotations

Marc Mosko <mmosko@parc.com> Mon, 03 August 2020 18:07 UTC

Return-Path: <mmosko@parc.com>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF993A07FB for <icnrg@ietfa.amsl.com>; Mon, 3 Aug 2020 11:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=parc.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 pRm944P61QFi for <icnrg@ietfa.amsl.com>; Mon, 3 Aug 2020 11:07:31 -0700 (PDT)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2069.outbound.protection.outlook.com [40.107.236.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB723A07F8 for <icnrg@irtf.org>; Mon, 3 Aug 2020 11:07:30 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WIRW0tHl9PyO2Zjs004Z9ZjxRQex7jYPvHAftYflqTaEJ/ZK4WdbS1dic6UIt6lgOTY4Ykb6uzGl2DmBmm+7rS3zszvrUI7HKGKn1yBMTD725lt6TB5grJFeCXhQJPM3D5JJsj/9Pnugkn9+8kf/mJR85EnAcqVui5HPGhP4WMIek7yt2RdAWJJT7TgbLY8z/saLbV7o/80n/q63+9MmxmJOD/wnH0Pe7hFg2IMoFkxGAnp+xB+n4S0Fq/JpLiAgzHnf8P8YqTr8oHAECWnp9GJa1gtTAqlNLxN3v5i7B9JS35xV+jRZeiujE9ehLMMH+O3QUN9t4z8OWatSVT3W4A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X1H1Hq/0e/GqLW964xZVTtjk8VfYZ536ZGF9qnio0f4=; b=F9aXiZ4yiShmefQEjX4UXSxVe9q8qoNjFL756lJpHSfv2P2Oncblx01EJ74V1/1UyvWSuzneZPl9/6KlF46Dtnjh114YLTPSvbJB9fpHt85r+iNNKb86hNBImA3Kpb2frvfXIkHQbFWE92hct/daT4t3lVNdgqxNNTAJM+uGeggOv5Wvfx5xulzAEuPGPOb/xbx7rht1UvSj7VzB9E/wQVXnY0pqxPig+fC4tEkshc2rd+oFeqFGv8CYs+GuQ7QTSJHim/Jw9oqROuu3KEAvDDEve26k7EiPrm8E1/zZngvbYF2Qjr1oQ+Nr7sxscRyrPiveLmKrpaVM5rOS8u6+6w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=parc.com; dmarc=pass action=none header.from=parc.com; dkim=pass header.d=parc.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parc.onmicrosoft.com; s=selector2-parc-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X1H1Hq/0e/GqLW964xZVTtjk8VfYZ536ZGF9qnio0f4=; b=NA71ZfaG7TzDKR7L+XrUS4FRJNoX/pk9vuVGv77I67B8DDkNsF7KJsOJs2Lv1oN3NKtAOclAh+hJ9aISPK5YSCsjTcNf6s99Vo/ghTDNMOFgs53MD2NLdIkV/EXCz8adBckSac7gERPjVuDlzeVVrNV/iFXzRNDIJ+jQQeLWjeM=
Received: from BYAPR15MB3238.namprd15.prod.outlook.com (2603:10b6:a03:106::29) by BYAPR15MB3271.namprd15.prod.outlook.com (2603:10b6:a03:101::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Mon, 3 Aug 2020 18:07:24 +0000
Received: from BYAPR15MB3238.namprd15.prod.outlook.com ([fe80::1045:4aad:16d6:c0e6]) by BYAPR15MB3238.namprd15.prod.outlook.com ([fe80::1045:4aad:16d6:c0e6%7]) with mapi id 15.20.3239.021; Mon, 3 Aug 2020 18:07:23 +0000
From: Marc Mosko <mmosko@parc.com>
To: "icnrg@irtf.org" <icnrg@irtf.org>
Thread-Topic: FLIC annotations
Thread-Index: AQHWacDwdHS9oKtJGUauG6Y8UVjucg==
Date: Mon, 3 Aug 2020 18:07:23 +0000
Message-ID: <C52CE20E-3342-46D1-9BD4-55BD630BF1C3@parc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.39.20071300
authentication-results: irtf.org; dkim=none (message not signed) header.d=none;irtf.org; dmarc=none action=none header.from=parc.com;
x-originating-ip: [50.0.67.90]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f2c5b73c-a992-44ff-5f35-08d837d812be
x-ms-traffictypediagnostic: BYAPR15MB3271:
x-microsoft-antispam-prvs: <BYAPR15MB3271334597CDD6E569091E5CAD4D0@BYAPR15MB3271.namprd15.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ZxuvfZLztweGkY1vYbyCMydnGHO2pgYXmPMuzhfLPRdwMf1VcApuRdwrJW6AZLeHKetWPp/cSeKo0m8UgCEGUxlxIvtdtMbXqHP8dcqfjvEoSOo3DTlK8Me2f25ATT7rEflZEyyE124PO5MaXpdayjTiqsfJRM3hNZRRED7kWflCYlbEjyf0JVNPPkUoBx/2eY5cWkiTrqxtaVZMsREe15ad5HprH4ekVYcoIHzvHUQjHayLEpczmFEKDs+x5rUwWARv/ZK8LGjCP9duqoOLE6KFCidxNpy6HVj5B6Bvn/p1OhBt+7SH1yqiavqeNPCLBxyoYnBUJBjqeOCcspZBB8Wxi27N+s/bNzr6zOdOdquCnL9CjMdHdZjlp5U9LVcHJkJRJRI4Fvk707AEPL7ObA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR15MB3238.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39840400004)(346002)(376002)(366004)(396003)(136003)(186003)(26005)(91956017)(66476007)(64756008)(66446008)(6506007)(76116006)(66946007)(66556008)(6486002)(36756003)(2616005)(71200400001)(5660300002)(83380400001)(8676002)(316002)(33656002)(3480700007)(86362001)(6916009)(478600001)(7116003)(6512007)(8936002)(166002)(2906002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: WzIoZEwJTC/8/NBEwgKdMdfgBQqhQZc6GWa9SrxyMQ7LHH5iFuze9Z2E7PDhcrEopB75LGeKMUcXLlNt0aJicZxJydlW13BUVJGvavNvpVdlFyTx0X4qQ+5vYQZFwwknGCNjU6syq+PVBGUGUZt9yF3WA6ULM9mYC1hudkRQJD+hCD+SFWp3RkBwvBSrl0TYqAFJAEI+Qf9HfrQPBM2U9xC7xOfM9YxIERyLiro4YcgFNYitZGfStkWoGJovkB3hUDT6YWz2Sr7wq31dvmmIEwTSlmLV2MurnOjmfem4bBs+WDenQRFOFhzJAknS0fB2G0aJPTT6N2IPVjJK2Ca0zxL5s4oCiu4djf1YEaQAE3SYZ2rvcYXErXAYyxzGAl0qC/5Q24nFwCN7eVUHkuGTscjs2t94no2VsqNSbPqe4QQOsNTte4pliG4Bl0WI+nx+pjChWYZ9tRKgPJozzLojFgyMAmGKoGseDvlahVFO8mNNkd/iRkYdtvinLboE5ydy5/TWQjxmKwAEP7//eMjKDNHVh1Or2/PCN6lYYD7K5sGBX8fcBMS8tSM0vMGpj6lPJZGZ0euyqmw0Vv3MNGI0Q2BpSBQq0vPbDwwiI/t94RJoBfpA2G0LXOj+PGlg+EyyZwk3Qmg+QrG9w9Dkv2HaFg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_C52CE20E334246D19BD455BD630BF1C3parccom_"
MIME-Version: 1.0
X-OriginatorOrg: parc.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR15MB3238.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f2c5b73c-a992-44ff-5f35-08d837d812be
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2020 18:07:23.7206 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 733d6903-c9f1-4a0f-b05b-d75eddb52d0d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pfaa3DWEpcCJryuOXD6Lm+wcFPXCq9ORf8qYv85nFxq/jQUiHs4aFpl+1jSxPVyi
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3271
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/Q6DvdcXIuxcViJLwyeZWczBJhYk>
Subject: [icnrg] FLIC annotations
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2020 18:07:33 -0000

This is one of a couple of emails on FLIC topics from today’s call.  This email focuses on the ability to annotate hash pointers in a FLIC manifest with metadata, such as size or pointer type (e.g. manifest, data), or decoding information (e.g. fec layers or video information).  On the call, we discussed three ways of doing it, which I summarize here.

Option 1: Next to the pointer (as it is written in -02)

A HashGroup can be a plain Pointer group or an Annotated Pointer group.  The format of each annotation TLV could be defined later, as it is its own TLV type inside an annotated group.


  1.  In a plain pointer group, there is one TLV that contains an array of hash values.
  2.  In an annotated pointer group, There is a TLV that contains a list of sub-TLVs, one for each pointer called a PointerBlock.  Inside that PointerBlock is an optional annotation TLV and a Pointer TLV containing a single hash value.

Option 2: Parallel Groups in one manifest

The supposed benefit of this is that a reader only needs to understand the HashGroup and could ignore the annotations.  Annotations structure could be defined later.  It leverages all the work on the basic manifest and a parser is the same for all the other things.


  1.  Define a HashGroup to be of the Plain type (#1 above) – an array of hash values.
  2.  Define other types of groups for annotations.  This moves the annotations to parallel groups, but still bundled within a single Manifest.

Option 3: Separate Data/Content objects within the FLIC world

One could always do separate metadata objects, but in this case there would be a specific mechanism within FLIC to inform the reader that a separate data structure exists and how to fetch it.  The format of the annotation object is wide open, but one could use the basic structure of FLIC.  A FLIC manifest would have a means to indicate to the reader that one or more parallel annotation trees exist and how to find them.

One possibility is to use the idea of Option 2 and move those annotation groups out of the plain FLIC manifest into an annotation manifest.

On a historical note, the earlier drafts on CCNx chunking (https://tools.ietf.org/html/draft-mosko-icnrg-ccnxchunking-01) included the idea of having the metadata in a separate object.  This was a 1-for-1 parallel scheme where the metadata for a chunk used a name tweak to point to the metadata.  This is an old concept from the early CCNx days of naming sidecar data.  The metadata option was dropped from the last revision (-02) of ccnxchunking to keep it simpler.

Option N: others?
The 3 above are what were brought up on the call.  Are there other options we should consider?

Security Considerations
The way the -02 FLIC draft is written, each Manifest object has a single encryption wrapper.  If one wants, for example, separate encryption for annotations from manifests, one needs to put the annotations in a separate object.  This most cleanly fits with Option #3.  One could change the encryption to work at the Group level to accommodate #2, but that will be pretty complicated pretty fast.

Marc