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

From: Yong-Geun Hong <[email-masked]>
Date: Mon, 12 Jul 2021 17:26:20 +0900

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 <[email-masked]>님이 작성:

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

> --
> [email-masked]