Re: [6lo] review of https://tools.ietf.org/html/draft-ietf-6lo-use-cases-07

Dear Pascal Thubert.

Thanks for your valuable comments.

These comments looks reasonable and are very helpful to improve the draft.

Please, find response inlines.

I will update the draft with your comments in a next revision.

Best regards

Yong-Geun.

On Wed, Oct 9, 2019 at 1:25 AM Pascal Thubert (pthubert) <pthubert@cisco.com>
wrote:

> Dear authors:
>
>
>
> Please find some comments below..
>
>
>
> «
>
>     some IEEE 802.15.4 link
>
> “
>
> Please reword to “IEEE Std 802.15.4”  and include a reference. You may
> use
>
>
>
>       <reference anchor="IEEE802154">
>
>          <front>
>
>             <title>IEEE Std. 802.15.4, Part. 15.4: Wireless Medium Access
>
>             Control (MAC) and Physical Layer (PHY) Specifications for
> Low-Rate
>
>             Wireless Personal Area Networks
>
>             </title>
>
>             <author>
>
>                <organization>IEEE standard for Information
> Technology</organization>
>
>             </author>
>
>             <date/>
>
>          </front>
>
>       </reference>
>
>
>
> Note that Thread and 6TiSCH use 6LoWPAN on 802.15.4 . This is worth
> mentioning. Thread has nice lighting use cases.
>

[Yong-Geun]  Yes. Current draft does't include a reference of "IEEE Std
802.15.4' I will include the reference.

>
>
>
>
> I do not see text on 802.11ah ? There has been 6lo work
> https://tools.ietf.org/html/draft-delcarpio-6lo-wlanah-01
>

[Yong-Geun] It is an interesting draft and I acknowledged it. Although it
is a relevant draft with 6lo use cases, we are trying to narrow down the
scope of this draft and we would consider how to handle the draft.

>
>
>
>
> Section 3.6 does not refer to the WIP on PLC:
> https://datatracker.ietf.org/doc/draft-hou-6lo-plc/
>

[Yong-Geun] Yes, it miss the PLC draft and current PLC draft is a WG draft.
I will reflect.

>
>
>
>
> Shouldn’t you have a section on Wi-Sun? see
> https://datatracker.ietf.org/doc/draft-heile-lpwan-wisun-overview/
>
> Note that this is also related to RFC 8036 together with PLC, should also
> be discussed next to your section .6. on Smart Grid
>
>
>

[Yong-Geun] In a previous draft, Wi-Sun and jupitermesh were included. With
the purpose of narrowing down the scope of this draft. we removed a section
on Wi-Sun and jupitermesh, becuase these are mainly based on IEEE 802.15.4.
We would consider how to handle Wi-Sun.

>
>
>
>
>    “
>
>    In the G3-PLC specification, the 6lo adaptation layer utilizes the
>
>    6LoWPAN functions (e.g. header compression, fragmentation and
>
>    reassembly)
>
>       “
>
>     Are you sure of that? I thought they used RFC 8066 to do their stuff
>

[Yong-Geun] I will check again.

>
>
> In section 5
>
>
>
> “
>
>       6LoWPAN requires that IPv6 Neighbor Discovery
>
>       for low power networks [RFC6775 <https://tools.ietf.org/html/rfc6775>] be used for autoconfiguration of
>
>       stateless IPv6 address assignment.  Considering the energy
>
>       sensitive networks [RFC6775 <https://tools.ietf.org/html/rfc6775>] makes optimization from classical
>
>       IPv6 ND [RFC4861 <https://tools.ietf.org/html/rfc4861>] protocol.
>
>
>
> “
>
>
>
> This text is a bit off: On the one hand autoconf is defined in RFC 4862.
> On the other hand RFC 8505 updates RFC 6775. It forgets to mention the
> obvious, which is to must IPv6 (RFC 8200)
>
> Then there’s more to be said about the support of IPv6 by the 6lo node.
> E.g., support of host functions in RFC 8200 like the capability to ignore
> consumed routing headers and HbH options. This become useful when combined
> with RPL, and a ref to
> https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo would be useful.
>
> I’d suggest:
>
>
>
> “
>
>       6LoWPAN developed a new version of IPv6 ND [RFC 4861, RFC 4862]
>
>      that relies on a proactive registration to avoid the use of
>
>       multicast. 6LoWPAN ND [RFC 6775, RFC 8505] inherits from IPv6 ND
>
>       for mechanisms such as SLAAC and NUD, but uses a unicast method
>
>       for DAD, and avoids multicast lookups from all nodes by using
>
>       non-onlink prefixes. A 6LN is also expected to be an IPv6 host
>
>       per [RFC 8200] which means it should ignore consumed routing
>
>       headers and HbH options; when operating in a RPL [RFC 6550]
>
>       network, it is also beneficial to support IP-in-IP encapsulation
>
>       [draft-ietf-roll-useofrplinfo]. the 6LN should also support
>
>       RFC 8505 and use it as the default ND method.
>
> “
>
>
>

[Yong-Geun] Thanks for your good suggestion. I will reflect.

>
>
> Voila, great doc by the way : )
>
>
>
> Pascal
>
>
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>