Re: [icnrg] icnrg Digest, Vol 101, Issue 8

Marc Mosko <mmosko@parc.com> Sun, 09 August 2020 22:51 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 9C8603A0E29 for <icnrg@ietfa.amsl.com>; Sun, 9 Aug 2020 15:51:39 -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, 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 q4JWVaOLTYPK for <icnrg@ietfa.amsl.com>; Sun, 9 Aug 2020 15:51:37 -0700 (PDT)
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2048.outbound.protection.outlook.com [40.107.243.48]) (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 BC6003A0E1E for <icnrg@irtf.org>; Sun, 9 Aug 2020 15:51:37 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MCy0JsSe6rOGeDHGWJwZPXADOmYKugwNwD4+lXG7SU/fJ7wNuAT16/VuBgFhJxeuDL5ovFrvcvangqiqERmWROqhLSQPzIXtidFwMxSpTUJKRJD79AQG2n//nnZK7c1hDsz85oN0vrEo1W9NxdPkt4gXJqEHH9/Oho0wxNdImK+/5W1rbAhUykp+8aElRaag2t9/NFtCElZEfPrWuSltLoMy8NQyju2hlpDv5qiVF32MhOAk3TL/EE4uvK/P2d7w8s6VrWxFB0eDsqZgA9oGUTgX5jZzYZiXyrRwXHZYbVLYXFl/M5sU9cJLInOQiYKDL3aCzWvpNh0wtDFURvP4NQ==
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=U1vlRaIxWnuh0DjbaUGXDKygDPDYHta731Tb3+c8AXk=; b=VUSf0UhI/RfFuz6BCzrjKmKGxMzTzWdtk+NnzjVBGHy48xRAXfE4o7l6iXzRk4RUW34hbTdEpN44ufQ1YX6FUpuMHEsCWwQ6xM5nPyU8bed/WGSm32I7tsE9EWMRMC8DwqQ/3SvdvtrcrP4LF7kLK7DSOOhUKPp4y02MWFuQJeRpw4ptkjAIfotN3n3werL6au5NjP9CHyP20y7E9LsEZYwUT9B7nLdMdMWQ3xks8HtT+4ZBUBkx71cCNdthw/LwgE1MdzjMxdvkYpr6gWimzjdjXRlhCrIL9eT0t+qsu7/NQiMw1iVW1KqxcxeHZ8J7p6W6WCdMaMBK2b1g98OVMw==
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=U1vlRaIxWnuh0DjbaUGXDKygDPDYHta731Tb3+c8AXk=; b=xsQlrQNqgCtvC0SEcbUc/4tCTjfrOKrjadbpqR5BgvQNjvxNGNju3UH8ogB024ugUYEUzdT89CsajXfzLq30hnyeJkKf7/cq5wb2qId1ewJVoLGAyyv1oqW5TQ2RdFagVmoes2ifPtYDGfPFlepGO+wOW/UBkSmhqPwQpOnbwBs=
Received: from BYAPR15MB3238.namprd15.prod.outlook.com (2603:10b6:a03:106::29) by BY5PR15MB3697.namprd15.prod.outlook.com (2603:10b6:a03:1b3::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.18; Sun, 9 Aug 2020 22:51:35 +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.3261.023; Sun, 9 Aug 2020 22:51:35 +0000
From: Marc Mosko <mmosko@parc.com>
To: Ken Calvert <calvert=40netlab.uky.edu@dmarc.ietf.org>, "icnrg@irtf.org" <icnrg@irtf.org>
Thread-Topic: [icnrg] icnrg Digest, Vol 101, Issue 8
Thread-Index: AQHWbbjd3NYo4oCX2U69+FfaNxdJLakv7nMA
Date: Sun, 9 Aug 2020 22:51:35 +0000
Message-ID: <A8A53463-3A1F-49AF-A4C4-4192E5749B4E@parc.com>
References: <mailman.835.1596746246.7280.icnrg@irtf.org> <B998AB47-A18A-4A6D-9AB0-541364B9B64F@netlab.uky.edu>
In-Reply-To: <B998AB47-A18A-4A6D-9AB0-541364B9B64F@netlab.uky.edu>
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: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.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: 2eea264d-c7aa-4440-36a0-08d83cb6c4cc
x-ms-traffictypediagnostic: BY5PR15MB3697:
x-microsoft-antispam-prvs: <BY5PR15MB3697DED3B1F36270BDBDC649AD470@BY5PR15MB3697.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: dg9fKnVkHu2AtSfuy7wROW4DVQAFx22CB0zN9pNra8X68cFAnkPcJlaoY3U7uQl2prre/n0QmEnZwhUfOWREkgdcfibEdK6ZI4bK5f/LUpDDGX2OsJkitWh5hIPAXfLFCjWJFNV7ufjT0V/jsU6aGFne58qapz5StGt8mPuJTzXVaZU3DAaJALW/m/IF5Pzq8DoIXAbdt2lVW7rSkYy/Yxi0R3IryuWnNhHmVuZ73wnuUA2IDQjh8yVtE5GErIZFweOw2ITIHhwBBUBA3HotLAxG7cm/q6xTndIcuqsHIzYkl1hs8uIkGwAqHDq5BigADQ6wLToQOaOvX4L5Co2GTHU3mt8SZfEm/wQX36NRHg9ap1BKo3KPCuvDuePf3Fg75rEDsWa/fXiYrmwK0YNLcw==
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)(64756008)(66446008)(66946007)(76116006)(2616005)(5660300002)(71200400001)(33656002)(8676002)(6486002)(86362001)(83380400001)(316002)(110136005)(66556008)(66476007)(2906002)(186003)(8936002)(6512007)(26005)(966005)(478600001)(6506007)(36756003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 8zdtuj67YtpIc1SsK0FktdiuJlpZA44zkRPL/bPaafAVyxX/Xc+44bsqpiiMH8PX/pWkwTW60MToPAHUHtx619W5kMR0+H/bTlWpFcfTCWe8RZeqqfl7ugqacPfXmB/KaB+ZFgHYjQgDm6jSfzhtzv+iZY/703LLqVMVesh60e1kwOFTcsB+TzMRwZ9OFa7q0YYP3GcSr/JNHYpPtoMrjIAnzj2encB4aSCnQCBvoQnsY+Mfprl/kHF10hWjyCVRKbbpB5r3LRzMCMhqhBtI1zX6/2AcfGOih8GfYbEIg5IATl3UCR/FnXcybN4XxgRTmQDuW3AuRJVMl8f8N4VjBLPna+WnDnetqWzJ1tkScVvQTwnpip1dF0YMcs9k1yczALxq3WYlZu5FC1LGEmOYTuWGc3oj7Nkp62+oMn4E3Jvc5t1zJkeFEPFlIN/JDnftcKHstEHEiwVhqmh7d7xuoZsqCoTLQRfddlfea/RyAwJr4MfRcvvf84Bi2mkC8CR4PQB5DcEMmvL1yGXDWJ0E6kPhYjaQmVARO5RQbvqjW30/at4x1UusEcQYa4/qrfTqC1CZix/kLM7t7DhX/4ZMmIcHEdWymc3cDUMhI53qoCgozU/vPCUGLiUkyzN5diYj2iw6JGmxGgCWJbBfMaeoCA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <ABA45D400CFC2D4699BE1AC4727018F1@namprd15.prod.outlook.com>
Content-Transfer-Encoding: base64
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: 2eea264d-c7aa-4440-36a0-08d83cb6c4cc
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2020 22:51:35.4688 (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: C8Yc+LdfJKtGGFlgnObZPfHCK3XJF2HSkYeI5DGaWOr6/c9KQijmJYx7n9Ljy79q
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR15MB3697
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/MHmjz56QjlUzaT6aUt-sjQIOTpA>
Subject: Re: [icnrg] icnrg Digest, Vol 101, Issue 8
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: Sun, 09 Aug 2020 22:51:40 -0000

  >
  >On 8/8/20, 12:19 PM, "icnrg on behalf of Ken Calvert" <icnrg-bounces@irtf.org on behalf of calvert=40netlab.uky.edu@dmarc.ietf.org> wrote:
  >
  >    Responding to a couple of points:
  >
  >    DaveO said:
  >
  >    > I’m still digesting this. Consider my comments more as questions, although all of you who know me also are aware of my predilection to couch questions as objections.
  >    > 
  >    > I also admit to not really understanding it completely after a couple of read-throughs. Some of this may be due to having to purge my translation cache of my usual understanding of some of the terms you have chosen. Feel free to respond, ponder for why the explanation isn’t getting through well to me, or just ignore.
  >
  >    I won't try to respond to your points (I'm already way behind), but I think maybe you and Christian are closer together than your reactions might indicate.
  >    For example, I interpreted his "virtual blob" in exactly the way you suggest.
  >
  >    Marc said:
  >
  >    > FLIC describes a single file.  No.  By definition, FLIC must always describe two files: the manifest and the data.
  >
  >    I think you mean to say "FLIC specification must always describe two types" here, right?

Well, the Manifest describes how to assemble all the pieces of the manifest into the correct order such that one can derive the correct order of data pointers from it.  The manifest is, at its base, an ordered list of pointers to data, plus a little extra for security context and maybe an annotation.  To me, that is the manifest file.  I could give you a single file (say json or binary) that conveys the same exact information as gets encoded in the manifest tree.  The manifest tree exists because we want to limit the size of the data transfer unit.

But this is a semantic point not really that important.  We could call it the manifest type or whatever.  My point is there's two things being conveyed: the manifest (data pointers) and the data itself.

  >
  >    > Inlining: Yes!  One use case we had for this was when someone wants to re-publish a manifest object (e.g. a content distributor wants to point its subscribers to local caches via locators), it would encapsulate the original root manifest in its re-written one so the consumer can verify in one step that they (a) got the thing they were asking for (from the interior manifest) and that someone they trust for such things (e.g. their ISP) tells them a good place to fetch it from.
  >
  >    Hmmm. This is different from my understanding of the "inlining" discussion.  As I said in my previous message, I interpreted it like what some filesystems do for inodes of small files: put application data directly in the inode/manifest structure.  I think the latter is a bad idea, for reasons I mentioned earlier.  OTOH, what you describe here, encapsulating metadata in other metadata, seems like just a normal thing you might do with a metadata-in-manifest facility.

Ok, I understand the distinction.  At some early point, it was decided that a Manifest should not carry application data in its payload.  I think that's fine.  

  >
  >    Ken
  >
  >    _______________________________________________
  >    icnrg mailing list
  >    icnrg@irtf.org
  >    https://www.irtf.org/mailman/listinfo/icnrg
  >