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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 [e-mail]<mailto:[e-mail]> and Himanshu Bhalla [e-mail]<mailto:[e-mail]>.


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 <[e-mail]> On Behalf Of Shwetha
Sent: dimanche 4 octobre 2020 09:03
To: [e-mail]
Subject: [6lo] 2nd WGLC for draft-ietf-6lo-use-cases

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/#<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