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

Yong-Geun Hong <yonggeun.hong@gmail.com> Mon, 12 July 2021 08:26 UTC

Return-Path: <yonggeun.hong@gmail.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E413A13E9; Mon, 12 Jul 2021 01:26:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgZMiNuTBLtH; Mon, 12 Jul 2021 01:26:33 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4547E3A13E0; Mon, 12 Jul 2021 01:26:33 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id f30so41773777lfj.1; Mon, 12 Jul 2021 01:26:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OzbIduXuIq5NeUbpmC5vaz14Pgf5a0CLaIA5VpV2tKM=; b=SvLybD3tD4sDqnkf9TSyvEul/+tu1nKbthnEW8eb+S19NC8/TCB1Tz71Mhgu5deI0R GFH5xjqc6V1oQe8xqw4FhS6SKbzjlFyNLgAzKI119MGoA/FJKXzIVZ6YvyN5Jkm+b+cr Y79Cx7hLGTcl6qUkgcRZquD7etoFg7MjhCgtnaoAK9UVeHC87rLrgAnaiMfRftT/DNK0 Kz3riKYfjliANLr8y+kz5JNY06Yp9U8OnidzulkfjEWanaowh5J0f1bpeUD87c5hwirJ LbaglCBZMLzGeLJZa7jVvkOGMi3vjL8/eqOmS5Z5ua1wUzy3dJSuGsOTKV91h0JKAj0p wFrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OzbIduXuIq5NeUbpmC5vaz14Pgf5a0CLaIA5VpV2tKM=; b=NjuarfhhYyEri/rIDACYAeoS34dHunF+j8fq88qtCof/AtIlwr/wE5WMwAdrJmKjOf uocxB9XiVjzOgPp8A23qY59+3M2FLiMb6dRPMN6TJJHQDgYJOHgAuA6Id4wCuCfeUQFu ttMPdkY/K5Ex/jSM3yWelPqaxWZ28I4/oDjO841muYIONuwyAQbNfHuvRdLH4umJAF+3 CwqRVwJGNI8k8CRulbADssNzauGj4UZXj8pBu71BMK/u/NYBT+JLZTW4QPjucTh3Vfvu /4XxA9hlrmxi+n+448Mt+OqHbI0Q9jhTC/8nPUa5v6miY71hon2pXh1FqrNR4o+tc2am LdPw==
X-Gm-Message-State: AOAM532afKcI6bzLGXZ+pb8Y7ywii0ivJDBjxtmlrUZH5JUC1UnFElkn PTkoDhUxhEBYkoVFZaxY2Zxc1iAh/40rQlCyudo=
X-Google-Smtp-Source: ABdhPJzxRhoxBF/RVU9jiAjRsIV9vGEb8M2tG2dxMVWtq7zmHWF7p4A1joFh7q72vSZv0XFFI11v/v/bLiLie4o7cIA=
X-Received: by 2002:a19:f806:: with SMTP id a6mr15286340lff.425.1626078390025; Mon, 12 Jul 2021 01:26:30 -0700 (PDT)
MIME-Version: 1.0
References: <24638.17861.668251.423193@fireball.acr.fi>
In-Reply-To: <24638.17861.668251.423193@fireball.acr.fi>
From: Yong-Geun Hong <yonggeun.hong@gmail.com>
Date: Mon, 12 Jul 2021 17:26:20 +0900
Message-ID: <CACt2foH5J6KyFZZYG2N7uw-P9Edv2zGEBHR6QtqWdiWPqFSdsQ@mail.gmail.com>
To: Tero Kivinen <kivinen@iki.fi>
Cc: lo <6lo@ietf.org>, draft-ietf-6lo-use-cases@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d080c005c6e8e092"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/oVt5iyhb3tyFUlV6aH-mpEJrQkk>
Subject: Re: [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: Mon, 12 Jul 2021 08:26:36 -0000

Dear Tero kivinen.

Sorry for the very long late response to your comments.

I appreciate your valuable comments and your comments are very helpful to
improve the draft.

Based on your comments, I updated the draft and submitted the
updated version.

Please see my response inlines.

Best regards.

Yong-Geun.

2021년 3월 2일 (화) 오후 11:04, Tero Kivinen <kivinen@iki.fi>님이 작성:

> 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.
>
[Yong-Geun] Thanks for your correction. As you said, we are trying to
capture the similar features of 6lo technologies and
it is difficult to follow the latest information of IEEE 802.15.9.  I
downloaded the specification of IEEE 802.15.9 and checked
the feature that you pointed out. I added a sentence that describes this
situation in the Introduction part.


> 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
> "Std".
>
[Yong-Geun] Thanks for your correction. I checked the expressions and
updated them with your points.


> 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.
>
[Yong-Geun] I checked the IEEE Std 802.15.4 document and updated the title
with the latest information.
And I also checked the IEEE Std 1901, IEEE Std 1901.1, IEEE Std 1901.2 and
there are no errors.


> 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.

[Yong-Geun] I agree with your point. I removed that sentence.


>
> --
> kivinen@iki.fi
>