Subject: [6lo] 2nd WGLC for draft-ietf-6lo-use-cases

From: Shwetha <[email-masked]>
Date: Sun, 4 Oct 2020 12:32:50 +0530

This initiates a 2nd WGLC on the use-cases and applicability draft:

https://datatracker.ietf.org/doc/draft-ietf-6lo-use-cases/

The first WGLC initiated in November 2018 didn't conclude due to lack of
responses. However the workgroup has reviewed the latest revisions and
authors have addressed the comments in -09 pending one comment
https://mailarchive.ietf.org/arch/msg/6lo/Ib4P3Zq-CCf6Ye4uKLU-NIHlp_I/#

As per the discussion at the 6lo session during IETF 108, this starts a
WGLC. This WGLC will conclude in two weeks on Monday October 19th.

Please send your comments to evaluate progressing this draft.

Thanks,
Shwetha

---

From: "Houjianqiang (Derek)" <[email-masked]>
Date: Tue, 13 Oct 2020 13:39:17 +0000

Dear all,

I have read through the paragraphs regarding PLC, and following are my comments:

1. IEEE 1901.1(PLC-IOT) is missing in the reference, and the recommended reference format can be as below:
[IEEE1901.1] "IEEE Standard for Medium Frequency (less than 12 MHz) Power Line Communications for Smart Grid Applications", 2018, https://standards.ieee.org/standard/1901_1-2018.html.

2. In section 6.6, there is one typo in the paragraph as below. This paragraph is introducing 1901.1, thus the " variant (IEEE1901.2)" should be " variant (IEEE1901.1)"
//////Example: Use of PLC (IEEE1901.1) for WASA in Smart Grid
   ///Many sub-systems of Smart Grid require low data rate and narrowband
   ///variant (IEEE1901.2) of PLC fulfils such requirements.  Recently,
   ////more complex scenarios are emerging that require higher data rates.

3. There is a small error in the table in section 3.6. The frequency range for IEEE1901.1 is smaller than 12MHz, not 15MHz

4. In section 3.6 PLC, there are 2 paragraphs introducing IEEE1901 and IEEE1901.2, but the introduction for IEEE1901.1 is missing. Here I write an example:
[IEEE1901.1] defines a medium frequency band (less than 12 MHz) broadband PLC technology for smart grid applications (SGPLC) based on orthogonal frequency division multiplexing (OFDM). By achieving an extended communication range with medium speeds, this standard can be applied both in indoor and outdoor scenarios, such as Advanced Metering Infrastructure (AMI), street lighting, electric vehicle charging, smart city etc.

B.R.
Jianqiang Hou (Derek)

发件人: Shwetha [mailto:[email-masked]]
发送时间: 2020年10月4日 15:03
收件人: [email-masked]
主题: [6lo] 2nd WGLC for draft-ietf-6lo-use-cases

The first WGLC initiated in November 2018 didn't conclude due to lack of responses. However the workgroup has reviewed the latest revisions and authors have addressed the comments in -09 pending one comment https://mailarchive.ietf.org/arch/msg/6lo/Ib4P3Zq-CCf6Ye4uKLU-NIHlp_I/#<https://mailarchive.ietf.org/arch/msg/6lo/Ib4P3Zq-CCf6Ye4uKLU-NIHlp_I/>

As per the discussion at the 6lo session during IETF 108, this starts a WGLC. This WGLC will conclude in two weeks on Monday October 19th.

Thanks,
Shwetha

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 13 Oct 2020 14:40:07 +0000

Dear chair and authors

Please find some WG LC comments below on draft-ietf-6lo-use-cases-09:

I feel there should be a pass on grammar by a native speaker before the IETF last call. Some things, mostly at the beginning,  sound strange to my hear but being non-native I do not feel entitled / capable to comment on that.

There are occurrences of mis-typing 6LoWPAN as below:

The IETF 6LoPWAN (IPv6 over Low powerWPAN)

The IETF 6LoWPAN (IPv6 over Low-Power WPAN)

See also

   Neighbor Discovery Optimization for 6LoPWAN [RFC6775<https://datatracker.ietf.org/doc/html/rfc6775>].

   Neighbor Discovery Optimization for 6LoWPAN [RFC6775<https://datatracker.ietf.org/doc/html/rfc6775>][RFC8505].

Not sure you need section 2 with the BCP 14 language. This is an informational draft

Section 3.2: the Bluetooth SIG is mostly done with the effort named "IP Link" within the Internet Workgroup, to provide an optimized transport over BLE 5 Extended Advertisements for 6LoWPAN HC and above it Thread. I believe that is worth mentioning? Contacts, if you need more, would be Martin Turon [email-masked]<mailto:[email-masked]> and Himanshu Bhalla [email-masked]<mailto:[email-masked]>.

Section 3.6 . G3 PLC uses an escaped 6LoWPAN, and you discuss it in 4.1. Why not a word with a forward reference here?

Section 4 has G9903 and Netricity but IMHO it’s missing Wi-SUN (https://wi-sun.org/). This looks like an unfair omission. Wi-SUN combines 6LoWPAN and RPL, and arguably uses a different 802.15.4 since it is SubGig 15.4g, without the frame size constraint and multiple PHY rates. You may use https://tools.ietf.org/html/rfc8376#section-2.4 as a reference.

The major application is smartgrid AMI, but due to its slow channel hopping method, it is close ot 6TiSCH and provides a similar applicability, e.g., grid and factory automation.

Section 4 is also missing Thread https://www.threadgroup.org/. Arguably that is classical 802.15.4 but in fact since Thread is route-over, links of various MAC/PHY technologies could be integrated, think Wi-Fi or BLE. This is a better story for IPv6 than a home IoT networking technology like those listed in 6.1 or 6.3 which stick to a single MAC/PHY. Applicability includes home networks and building, e.g., for lighting.

Section 5 is really neat and useful. I’d love to see it earlier, why is it between 4 and 6???

One crucial point is the use of broadcast. Together with L3-routing, 6LoWPAN ND reduces that a lot vs. classical ND. Could you add words or a bullet on this, maybe splitting “o  Address Assignment:” into “o  Address Assignment:”, which is a bit long as is, and something like  “o broadcast avoidance:”

Section 5 mentions RPL several times; it also mentions 6LoWPAN ND (all good!). There was indeed a special effort integrating those two, and more.

* This effort shows in RFC 8138 (and https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/), which extends 6LoWPAN HC to compress also the RPL artifacts used when forwarding packets in the route-over mesh. This could be mentioned in the “
   o  Header Compression:” bullet.

* This effort also  shows in https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ that allows a 6LoWPAN node, called a RUL, to benefit from routing-over services in a RPL network without speaking RPL per se; instead, RFC 8505 is used as a protocol-independent registration to obtain routing services from RPL. The bottom line is that 6LoWPAN provides a rich host-to-router interface for constrained network, that is now leverage to enable router-to-router protocols (including RPL and RIFT). Maybe you could have a “o Host-to-Router abstract interface:” bullet?

* RFC 8505 is also used to request proxy ND services in case of a backbone, see https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/; you mention the backbone but not the backbone router.  Maybe that’s another bullet?

By the time you publish the next version AP-ND will probably be published as RFC 8928 (and 6BBR as RFC 8929)

6lo working group is working on address

      authentication [I-D.ietf-6lo-ap-nd<https://datatracker.ietf.org/doc/html/draft-ietf-6lo-use-cases-09#ref-I-D.ietf-6lo-ap-nd>] a

->

Address Protection for 6LoWPAN ND (AP-ND) [RFC8928] enables

Source Address Validation [RFC6620] and protects the

Address Ownership against impersonation attacks.

Section 6.3: the big thing with DECT is that the you get something like 20MHz of spectrum (and 10 channels) around the 1900MHz that is reserved for the usage of “cordless phones”. It is much easier to control its usage in a given area such as a factory or a hospital, so it is more suitable for critical applications than, say, Zigbee; I’d have loved a healthcare use case. But OK.

I hope this helps!

Keep safe,

Pascal

From: 6lo <[email-masked]> On Behalf Of Shwetha
Sent: dimanche 4 octobre 2020 09:03
To: [email-masked]
Subject: [6lo] 2nd WGLC for draft-ietf-6lo-use-cases

Thanks,
Shwetha

---

From: Seyed Mahdi Darroudi <[email-masked]>
Date: Wed, 14 Oct 2020 06:54:43 +0000 (UTC)

Dear Shwetha and authors

Thanks to authors. The document looks very good and well explained.
Just in case, I would recommend two minor updates:1- section 3.6 : The text “PLC is a data transmission technique that utilizes power conductors as medium” is duplicated.2- table 2 : In BLE column, more than RFC 7668, it also may need to be added  “I-D.ietf-6lo-blemesh”
Good luckSeyed Mahdi Darroudi
    On Sunday, October 4, 2020, 09:03:15 AM GMT+2, Shwetha <[email-masked]> wrote:  

The first WGLC initiated in November 2018 didn't conclude due to lack of responses. However the workgroup has reviewed the latest revisions and authors have addressed the comments in -09 pending one comment https://mailarchive.ietf.org/arch/msg/6lo/Ib4P3Zq-CCf6Ye4uKLU-NIHlp_I/#
As per the discussion at the 6lo session during IETF 108, this starts a WGLC. This WGLC will conclude in two weeks on Monday October 19th.
Please send your comments to evaluate progressing this draft.
Thanks,Shwetha_______________________________________________
6lo mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lo

---

From: "S.V.R.Anand" <[email-masked]>
Date: Fri, 16 Oct 2020 13:10:05 +0530

Dear authors,

I went through the draft and felt it is easily readable and well structured.
Thanks for the effort! There are few points I wish to mention.

- Refer to Section 5 "Guidelines for adopting IPv6 stack (6lo/6LoWPAN)".

   - Since the draft is about 6Lo, like other sections, it is better to use 
     only 6Lo in the section title just for consistency. 

   - Certain parts of the same section requires a bit of rewording so that the
     reader feels it is a 6Lo document rather than a summary of 6LoWPAN protocols.
     I know that the intention of the authors is to convey that the existing 6LoWPAN
     standards can be considered and adopted to 6Lo. 
   - For 6Lo networks that use wired link layer technologies, a short
     note on whether and how 6LoWPAN can possibly be adopted helps. 

- The emergence of BACnet IP as an alternative for BACnet MS/TP cannot be
  ignored. Considering the current and future trend, why the latter is still relevant 
  needs to be captured in the document to motivate the reader.

- Refer to 6.2 "Use case of Bluetooth LE: Smartphone-based Interaction"

  - The need for 6Lo for this use-case is not coming out clearly. It would be
    good to explain.

Hope the above inputs help!

Regards
Anand

> _______________________________________________
> 6lo mailing list
> [email-masked]

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 19 Oct 2020 22:20:11 -0400

---------- Forwarded message ---------
From: Kerry Lynn <[email-masked]>
Date: Mon, Oct 19, 2020 at 7:19 PM
Subject: Re: [6lo] 2nd WGLC for draft-ietf-6lo-use-cases
To: Shwetha <[email-masked]>

Dears Chairs and authors,

Here are some comments on the draft. In general the document is
well-structured
and readable and I hope it proves to be useful.

Page 3
As Pascal points out s/6LoPWAN/6LoWPAN/ in four places.
s/make the need/create the need/
s/are uniquely different from/expand upon/
I think the point here is that the different 6lo link layers are uniquely
suited to different applications?

Page 4
s/wire/wired/

Section 3.4 (page 6)
Please delete the last sentence as it basically repeats the first sentence.

Regards, Kerry Lynn