From ietf@dkutscher.net Thu Oct 26 00:00:42 2023 Return-Path: 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 ; 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 ; 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 ; 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 To: Marc Mosko Cc: icnrg 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: References: <169800833504.9432.569364798077227364@ietfa.amsl.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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2023 07:00:42 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_D0B5475F-1DC6-421C-BD83-F316833AC0CB_= Content-Type: multipart/alternative; boundary="=_MailMate_012D7C40-D2B6-461F-A6B5-C56668629800_=" Embedded-HTML: [{"plain":[152,4814],"uuid":"9238F393-4B3F-45E1-80B2-53C9688576CE"}] --=_MailMate_012D7C40-D2B6-461F-A6B5-C56668629800_= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Marc! We are going to discuss this in Prague =E2=80=93 @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 ca= n discuss the changes indicated in the new section 3.9.3, which follows u= p 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 i= n 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 e= ither the annotation method or group data method are valid. > * Added Section 3.9.3 as follows: > > 3.9.3. Segmented Schema Details > When using CCNx Segmented Prefix Strategy or NDN Segmented Prefix strat= egy, the consumer must determine the segment number to use in the name. T= here are two methods. > =C2=B7 If fetching a pointer with a SegmentIdAnnotation, the co= nsumer MUST use that segment number for the pointer. A pointer with Segme= ntIdAnnotation does not increment the SegmentId used by the GroupData cas= e. > =C2=B7 If the GroupData has a StartSegmentId parameter, then th= at segment number MUST be used for the first in-order pointer of the grou= p. The consumer then increments the segment number for each in-order poin= ter of that group. > Every group of a segmented NsId MUST have either a GroupData with a Sta= rtSegmentId, or use annotated pointers with SegmentIdAnnotation. > A segment number MUST indicate exactly one data item. That is, the prod= ucer MUST NOT duplicate the segment number in an object name for differen= t objects. The object hash MUST be the same for the same segment number o= f a name. > It is allowed to have multiple manifest entries with the same segment n= umber (see below). > While a producer is allowed to mix using GroupData StartSegmentId and S= egmentIdAnnotation, 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= =2E > Let us make this clear, the original data is constructed by the in-orde= r manifest retrieval, not the segment number order. We recommend that the= manifest in-order sequence SHOULD correspond to the segment number seque= nce. > 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. Thi= s can be used for data de-duplication, e.g. multiple occurances of the sa= me binary string within the reconstructed data object. If the producer us= es this method, then the data object cannot be reconstructed by simply fe= tching the sequence numbers in order. > Marc > > From: internet-drafts@ietf.org > Date: Sunday, October 22, 2023 at 1:58 PM > To: Christopher A. Wood , Christian Tschudin , Christopher Wood , David = Oran , Marc Mosko > 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=3Ddraft-irtf-icnrg-= flic-05 > > Abstract: > > This document describes a simple "index table" data structure and it= s > 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 --=_MailMate_012D7C40-D2B6-461F-A6B5-C56668629800_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks Marc!

We are going to discuss this in Prague =E2=80=93 @all, pl= ease have a look at the changes.

--
Dirk

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

I have uploaded t= he 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 t= han using implicit IDs or annotated pointers everywhere.

 

=
  • = Fixed the formatting of some figures and= example code.
  • = Added the SegmentIdAnnotation to the gra= mmar.  It was described in the text, but was not in the grammar.
  • = Added the new GroupData metadata of Star= tSegmentId.
  • = Updated the CCNx and NDN Segmented Prefi= x text to indicate that either the annotation method or group data method= are valid.
  • = Added Section 3.9.3 as follows:

 

=

3.9.3.=  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 meth= ods.

=C2=B7        = ; If fetching a pointer= with a SegmentIdAnnotation, the consumer MUST use that segment number fo= r the pointer. A pointer with SegmentIdAnnotation does not increment the = SegmentId used by the GroupData case.

=C2=B7        = ; 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 se= gment number for each in-order pointer of that group.

Every group of = a segmented NsId MUST have either a GroupData with a StartSegmentId, or u= se annotated pointers with SegmentIdAnnotation.

A segment numbe= r MUST indicate exactly one data item. That is, the producer MUST NOT dup= licate the segment number in an object name for different objects. The ob= ject hash MUST be the same for the same segment number of a name.<= /p>

It is allowed t= o have multiple manifest entries with the same segment number (see below)= =2E

While a produce= r is allowed to mix using GroupData StartSegmentId and SegmentIdAnnotatio= n, we in general do not consider that a good idea. It is up to the manife= st producer to ensure that every segment may be fetched. Segments, when f= etched in the manifest order reconstruct the data object= =2E

Let us make thi= s clear, the original data is constructed by the in-order manifest retrie= val, not the segment number order. We recommend that the manifest in-orde= r sequence SHOULD correspond to the segment number sequence.

A consumer is n= ot 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 t= o 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, t= hen the data object cannot be reconstructed by simply fetching the sequen= ce 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 Tsc= hudin <christian.tschudin@unibas.ch>, Christopher Wood <caw@heap= ingbits.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 organiza= tion. Do not click links or open attachments unless you recognize the sen= der 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<= br> Diff:     https://author-tools.ietf.org/iddif= f?url2=3Ddraft-irtf-icnrg-flic-05

Abstract:

   This document describes a simple "index table" data structur= e 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 collec= tion is a
   _manifest_ which acts as the collection's root node.  T= he 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

--=_MailMate_012D7C40-D2B6-461F-A6B5-C56668629800_=-- --=_MailMate_D0B5475F-1DC6-421C-BD83-F316833AC0CB_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQJHBAEBCgAxFiEELQg4ehlc0geFPhiSJ49JeaB3yowFAmU6DosTHGlldGZAZGt1 dHNjaGVyLm5ldAAKCRAnj0l5oHfKjA9nD/4n2Ru1syWNkTby9v/d90HermxgDKQM dHXEGdziPP5iLEJnuHdZ7gZOxzMzVnMU8HSH84rU9IbYWGRuf75dC4Wamk6Hl1nd 8w8V2arAiEvs8MI+a+FJtb0PPzVw0hmVcVyWL+FLX1aY4NBdQzM3xENCfOiLhfyB 9x2pXl06f8vjDvuBEbDvXtT5bFOwjd50vVCrVqYv1dYdnuiX372Jw0/cRVXRIhfw lj+3SKoaDlp/G4crWqKkwpSoKsLy9EGr0pveZa5FGkIJmU2PAVlVZYd6yHjROaef tzUCQf9IkMrfnYUtrXy7CBwJ1wz15ZNm/cvBZsfweRG4y4NwSlkLlrG/qEp2n9Bw cpgIf3H5y/GFjTCpv7/a3SCMw57PK4L6OgeQuvZbSHnkcK6zPF/w7r+y9QUNFJtT YLn7K67yKgs9dPfKX6UERjTCvwrPbhS4VL1eBuzLTVoCA9//MkEERW9olW9jZX0p kicOp3IS22CbwVol2I/dKImLNsC5YZZ7OL6rPibKb0I2aKwuGrj5Nf0sL3IIBttG muNSQQo7FDRUj6VT0upDGuRW/S2xXb+1nQahj/9n5R7YF9VL1+Ioa1eXXfOj1wpf bdMWDXa82onKyF5zVSOnEup03/Dn+VOTNY2siMFEYUzb/Bqv+tF8JVbdbzrFPwoZ ds3L51/y1TkFLA== =v/N8 -----END PGP SIGNATURE----- --=_MailMate_D0B5475F-1DC6-421C-BD83-F316833AC0CB_=--