Re: [icnrg] New Version Notification for draft-irtf-icnrg-flic-05.txt

Dirk Kutscher <ietf@dkutscher.net> Thu, 26 October 2023 07:00 UTC

Return-Path: <ietf@dkutscher.net>
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 B778FC1519A7 for <icnrg@ietfa.amsl.com>; Thu, 26 Oct 2023 00:00:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPUfXPqgCQ4t for <icnrg@ietfa.amsl.com>; Thu, 26 Oct 2023 00:00:38 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DAF8C1519AA for <icnrg@irtf.org>; Thu, 26 Oct 2023 00:00:37 -0700 (PDT)
Received: from [192.168.12.6] ([95.91.46.226]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1Mzi3l-1rinuT1vrV-00vfZX; Thu, 26 Oct 2023 09:00:33 +0200
From: Dirk Kutscher <ietf@dkutscher.net>
To: Marc Mosko <mmosko@parc.com>
Cc: icnrg <icnrg@irtf.org>
Date: Thu, 26 Oct 2023 15:00:27 +0800
X-Mailer: MailMate (1.14r5937)
Message-ID: <6624660E-D968-419C-AFA4-13E64A913999@dkutscher.net>
In-Reply-To: <BY3PR15MB4977E2E26DC78CCDC7EDDA0BADD9A@BY3PR15MB4977.namprd15.prod.outlook.com>
References: <169800833504.9432.569364798077227364@ietfa.amsl.com> <BY3PR15MB4977E2E26DC78CCDC7EDDA0BADD9A@BY3PR15MB4977.namprd15.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_D0B5475F-1DC6-421C-BD83-F316833AC0CB_="; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Provags-ID: V03:K1:4GtS/HoW39jzfTOjgGbf+VXN7GbbW5f9ws9KS0nhrM8vh6I2k9c USEgkUMnb3MnfSOmqQegXoX9QqITiLDpNfqnhhBEBpmbA0qacvrg9btbiZ33QnHraIMfpPq sO3gSHD22lozz0a6t0RgOq2aoirQPH6UeqQO/XrG53tAnOyJy+IN1GIjLmSQ2ryvgyJ8kGZ kpJmDlpA1Q0r+xtb4Dcdw==
UI-OutboundReport: notjunk:1;M01:P0:d+FwC9NePZI=;QnKK6WhhVxVH0dQ+d+Ln3dkaZjE 5A+q0ta2HEg+wa7vwaghfaVs1YHbZ5KJG6NeB1Z1Yc+vaxL0TACdFK2V+hqR79PytucNZx85d 2kZ94eMGakhgIw5t3yOBRXOEsOZRlyncFP+0vjZ0e6eSo3dMPsgPhkXW55EFpD0ZMLjrULTAL R4c799A+X2ZHJE3eHMv2LluhcE/6MDt+rin+3pvPJaoo7QBVw/kfPArfhkXiL49NlVUaZbWPI sEj4lDT4e+VDdS6bVuGBbP4gNuXs0dv3HvOSonCFffdtf0+WTQAulVz67+zIkQQxmDMgccCno gjHoNN3lI6Ib4V5JTPQ78fynqD1vrjASZvypfkK/CfLY72FTzKSUTpw1J5q1yp0YXrItZuv5s o2cUfdvlUzbZb0fGLMYJ86kxo+SnbOShqdQoaSY0lNwbnuMQytETwdLQ4emvKF8IeRgcIJhMS N1UX4vR2+3Pb/gkQzDrllDw2FOQ8E+Jw/SFYoi5Xcx+yU0c+UbcJGoFTScOS47DM1PljhroyR Rkiv1mRy9pqg5Ky60jSbU/7nOShKr8Qrh6pVWW4Ufv9D/ZnDW85WrBV77hiE4QE0ZRtKKfKQR KnfUMgdpYkwr6oZoVqHwQw4I/sV96D+GSUOggOV0wR9kgeucZ92bpbF7wuvNkom1DBIO2+DdR qjymSTzDJQfQWebYBRfd/zabYHc7oAml/5LS8IG+Rw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/YFLpk8lohUFkBM2AQyTBSH4v-98>
Subject: Re: [icnrg] New Version Notification for draft-irtf-icnrg-flic-05.txt
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://mailman.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://mailman.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Oct 2023 07:00:42 -0000

Thanks Marc!

We are going to discuss this in Prague – @all, please have a look at the changes.

--
Dirk

On 23 Oct 2023, at 5:07, Marc Mosko wrote:

> I have uploaded the FLIC-05 draft.  The deltas are listed below.  We can discuss the changes indicated in the new section 3.9.3, which follows up on the observation at IETF 116 that using a GroupData StartSegmentId is better than using implicit IDs or annotated pointers everywhere.
>
>
>   *   Fixed the formatting of some figures and example code.
>   *   Added the SegmentIdAnnotation to the grammar.  It was described in the text, but was not in the grammar.
>   *   Added the new GroupData metadata of StartSegmentId.
>   *   Updated the CCNx and NDN Segmented Prefix text to indicate that either the annotation method or group data method are valid.
>   *   Added Section 3.9.3 as follows:
>
> 3.9.3. <file:///Users/mmosko/Projects/ccnxtlv/icn-flic-manifest/src/draft-irtf-icnrg-flic-05.html#section-3.9.3> Segmented Schema Details<file:///Users/mmosko/Projects/ccnxtlv/icn-flic-manifest/src/draft-irtf-icnrg-flic-05.html#name-segmented-schema-details>
> When using CCNx Segmented Prefix Strategy or NDN Segmented Prefix strategy, the consumer must determine the segment number to use in the name. There are two methods.
> ·         If fetching a pointer with a SegmentIdAnnotation, the consumer MUST use that segment number for the pointer. A pointer with SegmentIdAnnotation does not increment the SegmentId used by the GroupData case.
> ·         If the GroupData has a StartSegmentId parameter, then that segment number MUST be used for the first in-order pointer of the group. The consumer then increments the segment number for each in-order pointer of that group.
> Every group of a segmented NsId MUST have either a GroupData with a StartSegmentId, or use annotated pointers with SegmentIdAnnotation.
> A segment number MUST indicate exactly one data item. That is, the producer MUST NOT duplicate the segment number in an object name for different objects. The object hash MUST be the same for the same segment number of a name.
> It is allowed to have multiple manifest entries with the same segment number (see below).
> While a producer is allowed to mix using GroupData StartSegmentId and SegmentIdAnnotation, we in general do not consider that a good idea. It is up to the manifest producer to ensure that every segment may be fetched. Segments, when fetched in the manifest order reconstruct the data object.
> Let us make this clear, the original data is constructed by the in-order manifest retrieval, not the segment number order. We recommend that the manifest in-order sequence SHOULD correspond to the segment number sequence.
> A consumer is not required to fetch every segment. A consumer may fetch segments in any order it chooses. It may skip around or omit segments.
> It is allowed to have multiple pointers to the same segment number. This can be used for data de-duplication, e.g. multiple occurances of the same binary string within the reconstructed data object. If the producer uses this method, then the data object cannot be reconstructed by simply fetching the sequence numbers in order.
> Marc
>
> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> Date: Sunday, October 22, 2023 at 1:58 PM
> To: Christopher A. Wood <caw@heapingbits.net>, Christian Tschudin <christian.tschudin@unibas.ch>, Christopher Wood <caw@heapingbits.net>, David Oran <daveoran@orandom.net>, Marc Mosko <mmosko@parc.com>
> Subject: New Version Notification for draft-irtf-icnrg-flic-05.txt
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> A new version of Internet-Draft draft-irtf-icnrg-flic-05.txt has been
> successfully submitted by Marc Mosko and posted to the
> IETF repository.
>
> Name:     draft-irtf-icnrg-flic
> Revision: 05
> Title:    File-Like ICN Collections (FLIC)
> Date:     2023-10-22
> Group:    icnrg
> Pages:    41
> URL:      https://www.ietf.org/archive/id/draft-irtf-icnrg-flic-05.txt
> Status:   https://datatracker.ietf.org/doc/draft-irtf-icnrg-flic/
> HTML:     https://www.ietf.org/archive/id/draft-irtf-icnrg-flic-05.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic
> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-irtf-icnrg-flic-05
>
> Abstract:
>
>    This document describes a simple "index table" data structure and its
>    associated Information Centric Networking (ICN) data objects for
>    organizing a set of primitive ICN data objects into a large, File-
>    Like ICN Collection (FLIC).  At the core of this collection is a
>    _manifest_ which acts as the collection's root node.  The manifest
>    contains an index table with pointers, each pointer being a hash
>    value pointing to either a final data block or another index table
>    node.
>
>
>
> The IETF Secretariat

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