Re: [icnrg] draft-irtf-icnrg-icnlowpan-08.txt

Colin Perkins <csp@csperkins.org> Wed, 28 October 2020 00:04 UTC

Return-Path: <csp@csperkins.org>
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 4C9033A098C; Tue, 27 Oct 2020 17:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=csperkins.org
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 b78IBErksihx; Tue, 27 Oct 2020 17:04:19 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 EE83B3A098B; Tue, 27 Oct 2020 17:04:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=OWbbNXuHZaDIwdJ1BOPVwgyEe4T5cZboD+lgB8zNP3Q=; b=BLY2G/oToPeYrlOVvm4lnuCYuU N8DllxEHK2GZx4e0O4lPyBTPV0rO48AjEBM3clSf9NqzmlKnY9MRcOlbjGnSJyG5Aht1p3tZ5etL4 yuFz1I/C0ocAyf8F8HyeX6Q10jwPK571V1PYm7T28fvxWzT8f40md6Wi9lSNPMVHFLQdwoGY+dg51 uBIOjiMIOE2A+UfJhIiPxRhY4YpQrAMQuDbcr1n7QVw8mDyyUMArrdXxPRafVAfytEbBTEk+a/qCo auJGVZtC6EqbB88gVcQXr087IDLEXfG4iKncomm3p7AVuNVTh7AxehjZ/xIYldJrZPx5XtZME3d6s gHLNUG8g==;
Received: from [81.187.2.149] (port=38036 helo=[192.168.0.67]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <csp@csperkins.org>) id 1kXYwr-00053S-Af; Wed, 28 Oct 2020 00:04:17 +0000
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <87h7quqhsd.fsf@gundogan.net>
Date: Wed, 28 Oct 2020 00:04:09 +0000
Cc: draft-irtf-icnrg-icnlowpan@ietf.org, ICNRG <icnrg@irtf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <069610A0-D096-4072-8A22-4A32EE51E234@csperkins.org>
References: <158832868689.11087.7358311653842055205@ietfa.amsl.com> <E1954083-8BA4-4173-A87E-EA87D5771C9F@tzi.org> <9900E3D1-11E4-461C-9B91-754E87527E6A@tzi.org> <87h7quqhsd.fsf@gundogan.net>
To: Carsten Bormann <cabo@tzi.org>, =?utf-8?B?Q2VuayBHw7xuZG/En2Fu?= <mail=2Bietf=40gundogan.net@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.104.17)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/F6Rs-z4fII6KACcHKYiR_WYsW_M>
Subject: Re: [icnrg] draft-irtf-icnrg-icnlowpan-08.txt
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: Wed, 28 Oct 2020 00:04:23 -0000

Thanks, Cenk – appreciate the details response.

Carsten – would you be able to check these responses, so the revision can be completed before the IETF 109 cutoff?

Cheers,
Colin





> On 16 Oct 2020, at 17:04, Cenk Gündoğan <mail=2Bietf=40gundogan.net@dmarc.ietf.org> wrote:
> 
> Hello Carsten,
> 
> thank you very much for this in-depth review and your helpful input
> .. and sorry for my late response.
> 
> We addressed your comments in this diff [1].  The file to generate this
> diff is also attached to this mail.  A brief summary to each of your
> points can be found inline below.
> 
> [1] https://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-irtf-icnrg-icnlowpan-08.txt&url2=https://inet.haw-hamburg.de/tmp/draft-irtf-icnrg-icnlowpan-09.txt
> 
> On Wed, Aug 26 2020 at 00:26 +0200, Carsten Bormann wrote:
> 
>> While we are resolving the code point issues, below are a few more questions I had.
> 
> The code point issue was resolved with the help of Carsten.  We freed
> some space by not requesting more code points than needed for the four
> uncompressed cases (CCNx/NDN-Interest/Data).
> 
>> 
>> Grüße, Carsten
>> 
>> 
>> # Major
>> 
>> An experimental RFC might want to specify a bit more about the experiment(s) that are planned to be made based on the protocol being defined.
>> 
> 
> We extended Section 10.2 with areas of future work and necessary
> experiments to advance the ICN LoWPAN work.
> 
>> In 5.3.2, how do I know that a Nonce is present?
>> (Optional in https://named-data.net/doc/NDN-packet-spec/0.3/interest.html)
> 
> The nonce appears as optional in the diagram, but the following
> paragraph on the website states:
> 
> "Name is the only required element in an Interest packet. Nonce is
> required when an Interest is transmitted over the network links, i.e., a
> compliant forwarder must augment the Interest with the Nonce element if
> it is missing"
> 
> In any case, we changed Section 5.3.2 to allow for optional nonces in
> the compression scheme without adding any overhead.
> 
>> 
>> 8.1: What do these conceptual contexts do?
>> I find nothing about that in here.
>> (RFC 6775 Section 7.2 has rules about context state evolution that probably are needed here as well.)
> 
> Beginning of section 8.1 briefly describes what can be encoded into a
> context.  The modified section 10.2 also picks up on this topic.
> 
>> 8.3: The meaning of Context ID chaining is not explained.
> 
> Chaining allows for using multiple context IDs within the same frame.
> An explanation is added to section 8.3.
> 
>> 
>> # Minor
>> 
>> The term “time-value” is used for what appears to be a duration, not an absolute time.  (Also, Figure 29 is highly misleading.)
> 
> Changed the definition to "offset" in Section 2 "Terminology".  Figure
> 29 is also modified to show the correct distribution.
> 
>> 
>> The discussion in Section 4.2 (as well as the Security Considerations for that) might benefit from a reference to
>> draft-ietf-6lo-minimal-fragment, in RFC editor queue.
>> Does icnlowpan have any opinion on fragment forwarding?
> 
> Added accompanying info on 6FF to section 4.2, 10.2, and 11.  Also added
> a reference to the evaluation on SFR and ICNLoWPAN that Martine
> mentioned a few weeks back.
> 
>> 
>> The term “link fragmentation” might more properly called “adaptation layer fragmentation”.
> 
> Changed, where appropriate.
> 
>> 
>> The neat unary encoding for NDN types assumes that type numbers stay low.
>> In uncompressed NDN, all numbers between 253 and 65535 have the same cost (three
>> bytes); here they have very different cost.
>> NDN might go ahead and allocate higher numbers without knowledge of the damage inflicted to the unary coding approach.
>> Looking at
>> https://named-data.net/doc/NDN-packet-spec/0.3/types.html
>> it seems that only the range 800-1000 has been allocated at a (still
>> small) detriment to this unary scheme.
>> (I don’t think the design is wrong, I’m just thinking about ways to communicate the importance of small type numbers into the greater NDN space.)
> 
> Section 10.1 now mentions that lower type numbers for frequently used
> TLVs are preferred and yield a better compression.  Out of scope of this
> document, but I could also think of a translation table that maps larger
> type numbers into the lower range (and probably sorts them by frequency)
> if they do too much damage.
> 
>> 
>> 5.2: Only the example says (implies) that the nibbles are used MSN first.
> 
> Added a more detailed explanation to section 5.2.
> 
>> 
>> # Editorial
>> 
>> Define byte and nibble at the outset and simplify some of the text.
> 
> Defined byte and nibble in Section 2 and replaced in the document where
> appropriate.
> 
> <draft-irtf-icnrg-icnlowpan-09.txt>
> -- 
> Cenk Gündoğan
> 
> Hamburg University of Applied Sciences
> Dept. of Computer Science / Internet Technologies Group
> Berliner Tor 7, 20099 Hamburg, Germany
> Fon: +49 40 42875 - 8426
> Mail: cenk.guendogan@haw-hamburg.de
> Web: https://www.inet.haw-hamburg.de/
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg