Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)
draft-irtf-icnrg-icnlowpan-11

(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has completed its review of draft-irtf-icnrg-icnlowpan-10. If any part of this review is inaccurate, please let us know.

We understand that when this document is sent to us for processing, we will add the following entries to the Dispatch Type Field registry at

https://www.iana.org/assignments/_6lowpan-parameters

The designated experts have reviewed these registrations and recommended that page 14 be assigned if that value is still available when the document is sent to us for processing:

+-------------+------+-------------------------------------------+
| Bit Pattern | Page | Header Type                              |
+-------------+------+-------------------------------------------+
|  00 000000  | TBD1 | Uncompressed NDN Interest messages        |
|  00 100000  | TBD1 | Uncompressed NDN Data messages            |
|  01 000000  | TBD1 | Uncompressed CCNx Interest messages      |
|  01 100000  | TBD1 | Uncompressed CCNx Content Object messages |
|  10 0xxxxx  | TBD1 | Compressed NDN Interest messages          |
|  10 1xxxxx  | TBD1 | Compressed NDN Data messages              |
|  11 0xxxxx  | TBD1 | Compressed CCNx Interest messages        |
|  11 1xxxxx  | TBD1 | Compressed CCNx Content Object messages  |
+-------------+------+-------------------------------------------+

Thank you,

Amanda Baber
Lead IANA Services Specialist

IRSG final poll completed with only minor comments. Please review the comments in the datatracker and update the draft if necessary, then I expect this to be ready for IETF conflict review and publication.

[Ballot comment]
(Dummy edit, to check if an email goes out this time.)

Section 3.2., paragraph 3:
>    The stateless header compression scheme makes use of compact bit
>    fields to indicate the presence of optional TLVs in the uncompressed
>    packet.  The order of set bits in the bit fields corresponds to the
>    order of each TLV in the packet.

  Ordering by value (vie the bitfield) can lead to reordering of TLVs
  after compression/decompression - I assume that is OK?

Section 5.1., paragraph 0:
> 5.1.  TLV Encoding

  Any reason why an RFC6256 encoding wasn't chosen here instead of
  inventing a new scheme?

Section 7., paragraph 1:
>    This document adopts the compact time representation
>    [I-D.gundogan-icnrg-ccnx-timetlv] for relative time values.

  Maybe this draft should then normatively depend on the specification
  in [I-D.gundogan-icnrg-ccnx-timetlv] instead of duplicating it here?


Section 13.2., paragraph 2:
>    [I-D.gundogan-icnrg-ccnx-timetlv]
>              Gundogan, C., Schmidt, TC., Oran, D., and M. Waehlisch,
>              "An Alternative Delta Time encoding for CCNx using
>              Interval Time from RFC5497", draft-gundogan-icnrg-ccnx-
>              timetlv-00 (work in progress), November 2019.

  Outdated reference: A later version (-01) exists of
  draft-gundogan-icnrg-ccnx-timetlv-00


Section 13.2., paragraph 3:
>    [I-D.ietf-6lo-fragment-recovery]
>              Thubert, P., "6LoWPAN Selective Fragment Recovery", draft-
>              ietf-6lo-fragment-recovery-21 (work in progress), March
>              2020.

  Outdated reference: draft-ietf-6lo-fragment-recovery has been
  published as RFC 8931


Section 13.2., paragraph 4:
>    [I-D.ietf-6lo-minimal-fragment]
>              Watteyne, T., Thubert, P., and C. Bormann, "On Forwarding
>              6LoWPAN Fragments over a Multihop IPv6 Network", draft-
>              ietf-6lo-minimal-fragment-15 (work in progress), March
>              2020.

  Outdated reference: draft-ietf-6lo-minimal-fragment has been published
  as RFC 8930

[Ballot comment]
Section 3.2., paragraph 3:
>    The stateless header compression scheme makes use of compact bit
>    fields to indicate the presence of optional TLVs in the uncompressed
>    packet.  The order of set bits in the bit fields corresponds to the
>    order of each TLV in the packet.

  Ordering by value (vie the bitfield) can lead to reordering of TLVs
  after compression/decompression - I assume that is OK?

Section 5.1., paragraph 0:
> 5.1.  TLV Encoding

  Any reason why an RFC6256 encoding wasn't chosen here instead of
  inventing a new scheme?

Section 7., paragraph 1:
>    This document adopts the compact time representation
>    [I-D.gundogan-icnrg-ccnx-timetlv] for relative time values.

  Maybe this draft should then normatively depend on the specification
  in [I-D.gundogan-icnrg-ccnx-timetlv] instead of duplicating it here?


Section 13.2., paragraph 2:
>    [I-D.gundogan-icnrg-ccnx-timetlv]
>              Gundogan, C., Schmidt, TC., Oran, D., and M. Waehlisch,
>              "An Alternative Delta Time encoding for CCNx using
>              Interval Time from RFC5497", draft-gundogan-icnrg-ccnx-
>              timetlv-00 (work in progress), November 2019.

  Outdated reference: A later version (-01) exists of
  draft-gundogan-icnrg-ccnx-timetlv-00


Section 13.2., paragraph 3:
>    [I-D.ietf-6lo-fragment-recovery]
>              Thubert, P., "6LoWPAN Selective Fragment Recovery", draft-
>              ietf-6lo-fragment-recovery-21 (work in progress), March
>              2020.

  Outdated reference: draft-ietf-6lo-fragment-recovery has been
  published as RFC 8931


Section 13.2., paragraph 4:
>    [I-D.ietf-6lo-minimal-fragment]
>              Watteyne, T., Thubert, P., and C. Bormann, "On Forwarding
>              6LoWPAN Fragments over a Multihop IPv6 Network", draft-
>              ietf-6lo-minimal-fragment-15 (work in progress), March
>              2020.

  Outdated reference: draft-ietf-6lo-minimal-fragment has been published
  as RFC 8930

[Ballot comment]
This is a good basis for running experiments with ICN in constrained node network environments.
There are a few nits left, at least one of which needs to be addressed before moving this forward to the next process step.

The "C" flag is rather confusing for the reader (set to 0 for compression); could this be an "U" (uncompressed) flag?
Clearly, the erroneous Table 1 reflects the need for such a change.

RFC 8930 and related have been published; this puts the present specification on somewhat firmer ground.

Carsten Bormann completed initial review for IRSG. Some editorial comments sent direct to authors. Also concerns about IANA registration of code-points to resolve with the authors and designated IANA expert. Further review comments to come.

1) Summary
This document defines a convergence layer for CCNx and NDN over IEEE
802.15.4 LoWPAN networks.

2) Review and Consensus
The draft has received fruitful reviews by members of the ICN
community and the research group for a period
of two years. It is the consensus of ICNRG that this document should
be published in the IRTF Stream of the RFC series.