[6lo] Review of draft-ietf-6lo-use-cases-10

Tero Kivinen <kivinen@iki.fi> Tue, 02 March 2021 14:04 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 30B943A188D; Tue, 2 Mar 2021 06:04:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QLOLdzHhczqL; Tue, 2 Mar 2021 06:03:58 -0800 (PST)
Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24503A188C; Tue, 2 Mar 2021 06:03:57 -0800 (PST)
Received: from fireball.acr.fi (fireball.acr.fi []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 0C2721B00046; Tue, 2 Mar 2021 16:03:50 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1614693830; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=DSnALRV4uJtH+AG0v02hhGsLXE2FLfuswD0P4AQ+pEg=; b=MjwA5CwWckb/pMB9NmA94kbuubcqkKIB+vARXXpIcqKj13Z/T23nC7Y60g3SxEy0XFYjs6 kzVE2Q8y5eGRfnfb0agJ+7dBFexN7vGFJgKdxA+PB8HOqa4goRl2S/z/Tte6pkJdiT9Srp LLe7UsXYofSF95qQdfAHl1HV2LtVwngvbOrMSKL0j5TygF+LKCt+iAOWurVX7aHTD9hpxn 7Br7wD88WjFjzFKql03yGIIju0tPXz00Ai6MfmkNC5+229C9e+AMRCwSe69cPeKd7ew9bE kEZmdo6TThrjd1KYM4Bm0AZFOVH3g+sD/S3bKLgeBM9ijS12rWX2Zr6MIq34MA==
Received: by fireball.acr.fi (Postfix, from userid 15204) id AFB5725C0F74; Tue, 2 Mar 2021 16:03:49 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID: <24638.17861.668251.423193@fireball.acr.fi>
Date: Tue, 2 Mar 2021 16:03:49 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: 6lo@ietf.org
CC: draft-ietf-6lo-use-cases@ietf.org
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 39 min
X-Total-Time: 72 min
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi
ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1614693830; a=rsa-sha256; cv=none; b=OLw5mHHcCLZwAEbsBS38bqKHE735/AIDQtFzYYJmUBN4sG3P4hmcaxpILrLppUZ0rjotA6 7RKRq71WamUB9AG49sWHAjeUh7mBV/bAvpTGMq5oQ7Gx8JBoFQan/2rTDx4lDp3wSrRpFr EbLmFgzKgrK81ZIEDJIrV6q6108rWdGKknmSXdDQH1cKGU6oZtqgmdrdU7+sXYIu7VuYs5 v+LxZGO/9ohic/ohxftK1y6hBEATDEKQdi36ZDhwmLRuMk3AvBSdx6hbKbG6zCuX+4mIV2 Mvr/K+r55VrMVYhTt8TOcTCMNDnd0LPfyZAhpJEYnubXB8uKfDghbH3rrbHqlg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1614693830; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=DSnALRV4uJtH+AG0v02hhGsLXE2FLfuswD0P4AQ+pEg=; b=pJU+wYfXaJ4YFOzgRQ8Rc1K+Y6Weo+sQf7Y7k354gs16XAhagKWs+vDmw35G4bCfIl76Qo y8Pnx/Sxp00BccHCcD80JT0LiTT1Br+NyEcDt/cez+KdiIQYD13hyqL7RvSERivGdt66e7 0Xk7ChKAMZdqNnaqDTtb6gRukCGLA3FD8uX9nHNR7/cHg7e+EtFmAuHZfoSd9i+IzKZr+9 ClMTZ9e7SacbXBQsfT+Ki0uvQr1v5NV03bLJhqyNCIzx2EEJBNMfG84/ibEWAa3gpGrymd jc5uwE1jR1mpTom+telO4IHD8obxeq98sUTkQfmLNpZb+xceYX3JapsQh2JikQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/c5znteiwKqbt7wktNuzn2glxmbE>
Subject: [6lo] Review of draft-ietf-6lo-use-cases-10
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2021 14:04:01 -0000

In the introduction there is text saying:

   Furthermore, those IEEE 802.15.4 variants do not offer fragmentation
   and reassembly functionality.

This does not take in to account the IEEE Std 802.15.9-2016
recommended practice which provides multiplexing and fragmentation
layer for the IEEE Std 802.15.4. There is currently ongoing revision
process of that document that will change its from recommended
practice to standard. IEEE Std 802.15.9 is already widely implemented
on some of the environments using IEEE Std 802.15.4, which is the
reason it is upgraded from the recommend practise to standard.

IEEE Std 802.15.9 fragmentation allows splitting the larger upper
layer frame to multiple fragments. This allows transport of frames
over 24kB of length over the PHY that supports 127 octet frames.

IEEE Std 802.15.9 also provides multiplexing layer using EtherTypes,
thus it allows running multiple protocols over the same IEEE Std
802.15.4 network.

I do understand that IETF has also provide similar features allowing
fragmentation and reassemby of IPv6 packets, but perhaps this document
should also note that in some IEEE Std 802.15.4 networks those might
not be needed, and the methods provided by the IEEE Std 802.15.9 could
also be used.

The main driver for the IEEE Std 802.15.9 was to provide key
management for IEEE Std 802.15.4, i.e., allow using IEEE Std 802.1X,
HIP, or IKEv2 etc to create keying material for the IEEE Std 802.15.4
link (there is no guidelines how to use TLS in IEEE Std 802.15.9, as
nobody has shown any interest on that). 

If I remember correctly Wi-SUN is one of those people who do use IEEE
Std 802.15.9.

As a nit, the proper way to refer to the IEEE Standards is to use
"IEEE Std 802.15.4" or "IEEE Std 1901-2010" if dated version is
needed. Note the "Std" between the IEEE and the standard number, and
that there is no "." after the Std. There is several references to
"IEEE 802.15.4", or "IEEE 1901-2010" etc in the RFC. Also in the
normative referneces there is version which have "Std." instead of

Normative references also has old title for IEEE Std 802.15.4. The
title used there was changed in 2011 to "Part 15.4: Low-Rate Wireless
Personal Area Networks (LR-WPANs)", then simplified in 2015 to "IEEE
Standard for Low-Rate Wireless Personal Area Networks (WPANs)" and
simplified again in 2020 to "IEEE Standard for Low‐Rate Wireless
Networks". I did not check whether the IEEE Std 1901 standard names
are correct.

Also refering to the dated references (like "802.15.4-2006") or
specific amendments (like "802.15.4g") is always problematic,
especially as the underlaying standards evolve, and the groups start
using newer versions when they publish new revisions of their draft.
Refering to specific amendment where there is already new revision
out, is like refering to the specific RFC even when it is already
obsoleted by the newer one. When there is new revision that includes
all amendments published prior the revision, thus there is no longer
any need to refer any amendments separately, you should always refer
to the revision instead.

For example I am not sure current Thread group uses IEEE Std
802.15.4-2006 anymore, i.e., any features that were there in 2006, but
which are no longer in newer versions (i.e., features which were
deprecated). Thread 1.2 white paper talks only about IEEE
802.15.4-2015, which was the latest version when that whitepaper was
written (2019), but I think Thread group did provide some comments
during the IEEE Std 802.15.4-2020 revision process, so they might have
moved to latest version already.

Anyways providing such level of details is unnecessarely and might be
misleading when those external standards evolve, so I would recommend
removing that kind of version specific details.