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

Ken Calvert <calvert@netlab.uky.edu> Sat, 08 August 2020 19:19 UTC

Return-Path: <calvert@netlab.uky.edu>
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 2D7D83A0CA5 for <icnrg@ietfa.amsl.com>; Sat, 8 Aug 2020 12:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netlab.uky.edu
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 AL7tjyuykWeM for <icnrg@ietfa.amsl.com>; Sat, 8 Aug 2020 12:19:29 -0700 (PDT)
Received: from mail.netlab.uky.edu (mail.netlab.uky.edu [128.163.140.42]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A633A0CA7 for <icnrg@irtf.org>; Sat, 8 Aug 2020 12:19:28 -0700 (PDT)
Received: from hardy.local (cpe-96-29-182-38.kya.res.rr.com [96.29.182.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netlab.uky.edu (Postfix) with ESMTPSA id 06836180A8 for <icnrg@irtf.org>; Sat, 8 Aug 2020 15:19:27 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netlab.uky.edu; s=default; t=1596914367; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=E8aS1e3b5vrmN3TghXSwN57ydNqqcbge1X3LHNchX6g=; b=cGLB29g1h7UGFtfPyQILVNmjPwRSrNg2Qp9D6espnlSvhzTOWlGfCetxDUTAhlLB5vKyNq xjVNLc6LgSXs3nuuKnE948g2grhJPa9EUUfRYtY9Lcs40gfD5imUuuQPPfsi/4wBNF3UFs bNN0R3p3w9RPPg6zsfEXQ0TloLm00M539fBZdiiY4beEHjgMP+NMlQVHPfgVCa1vGzAVzB tlGOagkyqnbCCMkNu8X0xBgyTfANa+gUNSkJjTaaPljFZ4V/+sV4UAa+yKNUawZhUYtgI1 z+W0VM4AhoTQmLQfjXX6m91vRn5yGJLC9YX1Gv/ZptB7YVytS10xAT84jEKlvw==
From: Ken Calvert <calvert@netlab.uky.edu>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Sat, 8 Aug 2020 15:19:24 -0400
References: <mailman.835.1596746246.7280.icnrg@irtf.org>
To: icnrg@irtf.org
In-Reply-To: <mailman.835.1596746246.7280.icnrg@irtf.org>
Message-Id: <B998AB47-A18A-4A6D-9AB0-541364B9B64F@netlab.uky.edu>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=netlab.uky.edu; s=default; t=1596914367; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=E8aS1e3b5vrmN3TghXSwN57ydNqqcbge1X3LHNchX6g=; b=SaVNSqizUUz07EYONg/Vzyujn6AjXXYE2jHI1ZJnSfZzFWbpODlBVlHc2FzR5jZRN4jNXO QwaEz0e3s4YO4n1emERMDIKeswAHH+nFziZN9jrI/7UN35kJ5L7S0QgBO0oUvlbyyFBut8 4vHBqsV0tpA1Ea1RrwJaTGG6NYXWJOrnrxEyt09z5Xaff6PIImXJTZs57iJvjTlBkDHQP+ 87hxS5jmBfU2huqg3rtZH8kSoCGr+wXLo3dpGDUmStYcgruaGh8b5ayhGN+Kq1VZgP8fKI P7YoACDcrdXSyTFX8WdcqhKhK8MItAmjBu4w5zQZbZnaCiUVSJqBT7878Bd53w==
ARC-Seal: i=1; s=default; d=netlab.uky.edu; t=1596914367; a=rsa-sha256; cv=none; b=Yn2zyhFslavrz2Ujnn1/Xhtzq5Wp/kGdMg/+dUfr8XhM4+JBJovOuE54clA+5vtMnuqoMK 5Cl7EoinTmRnbTe6ZuDY3PzIDKSsXbwRCR91dy2SEco7vV9AnkXDSSza/dfxEWSrOJB6LB hYkL5j/UTwgUK7Ej0g88VKVym1lBkaPgbKrenWQZjXdFJnyEgCo/omWXE+DuD/jeTYMyq7 RIXu4o0SFuS1yzAnL901A9G/8SgrxUqIe7GxnYgwUt4x3oK0hqLaDkgptfffjc59n1BgYh lqtPE9ZzPVfyzFRGTBx8W+SkZZhLwm/mRAlCLUvl2udeMavoRKuxaFDBobiB5g==
ARC-Authentication-Results: i=1; mail.netlab.uky.edu; auth=pass smtp.auth=calvert@netlab.uky.edu smtp.mailfrom=calvert@netlab.uky.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/YIjJd1Yob0QQRkd-cK36y9BpR4E>
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: Sat, 08 Aug 2020 19:19:30 -0000

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?

> ...


> 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.

Ken