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

Carsten Bormann <cabo@tzi.org> Tue, 25 August 2020 22:26 UTC

Return-Path: <cabo@tzi.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 594A63A08B1 for <icnrg@ietfa.amsl.com>; Tue, 25 Aug 2020 15:26:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level:
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 XnN30GShBqEg for <icnrg@ietfa.amsl.com>; Tue, 25 Aug 2020 15:26:22 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 059B33A0814 for <icnrg@irtf.org>; Tue, 25 Aug 2020 15:26:21 -0700 (PDT)
Received: from client-0225.vpn.uni-bremen.de (client-0225.vpn.uni-bremen.de [134.102.107.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Bbk9R3CcdzyXv; Wed, 26 Aug 2020 00:26:19 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <E1954083-8BA4-4173-A87E-EA87D5771C9F@tzi.org>
Date: Wed, 26 Aug 2020 00:26:19 +0200
Cc: draft-irtf-icnrg-icnlowpan@ietf.org, icnrg@irtf.org
X-Mao-Original-Outgoing-Id: 620087179.032164-b47158cf74fb685f190d989fb9fa00f5
Content-Transfer-Encoding: quoted-printable
Message-Id: <9900E3D1-11E4-461C-9B91-754E87527E6A@tzi.org>
References: <158832868689.11087.7358311653842055205@ietfa.amsl.com> <E1954083-8BA4-4173-A87E-EA87D5771C9F@tzi.org>
To: Carsten Bormann <cabo@tzi.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/X8xdS-6kI9xtGyKV6tdSsH1TL6Y>
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: Tue, 25 Aug 2020 22:26:32 -0000

While we are resolving the code point issues, below are a few more questions I had.

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.

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)

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.)
8.3: The meaning of Context ID chaining is not explained.

# Minor

The term “time-value” is used for what appears to be a duration, not an absolute time.  (Also, Figure 29 is highly misleading.)

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?

The term “link fragmentation” might more properly called “adaptation layer fragmentation”.

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

5.2: Only the example says (implies) that the nibbles are used MSN first.

# Editorial

Define byte and nibble at the outset and simplify some of the text.