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

[Colin Perkins <[e-mail]>]

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=[e-mail]> 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: [phone] - 8426
> Mail: [e-mail]
> Web: https://www.inet.haw-hamburg.de/
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg