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

[Cenk Gündoğan <[e-mail]>]

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.

-- 
Cenk Gündoğan

Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: [phone] - 8426
Mail: [e-mail]
Web: https://www.inet.haw-hamburg.de/