[icnrg] Lars Eggert's No Objection on draft-irtf-icnrg-icnlowpan-09: (with COMMENT)

Lars Eggert via Datatracker <noreply@ietf.org> Tue, 08 December 2020 13:27 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: icnrg@irtf.org
Delivered-To: icnrg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 520D53A0D3C; Tue, 8 Dec 2020 05:27:08 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Lars Eggert via Datatracker <noreply@ietf.org>
To: "The IRSG" <irsg@irtf.org>
Cc: draft-irtf-icnrg-icnlowpan@ietf.org, icnrg-chairs@ietf.org, icnrg@irtf.org, Dirk Kutscher <ietf@dkutscher.net>, ietf@dkutscher.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Lars Eggert <lars@eggert.org>
Message-ID: <160743402831.16659.691683338760896532@ietfa.amsl.com>
Date: Tue, 08 Dec 2020 05:27:08 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/vMNC9diFBTnlhVxJTq8hj8gEFZc>
Subject: [icnrg] Lars Eggert's No Objection on draft-irtf-icnrg-icnlowpan-09: (with COMMENT)
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
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, 08 Dec 2020 13:27:09 -0000

Lars Eggert has entered the following ballot position for
draft-irtf-icnrg-icnlowpan-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:


(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

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