Hello Sajjad,

Many thanks to your comments. We have uploaded the 05 version of the draft. The 
modification is based on the previous comments that we received these days. The 
fragmentation section is also clarified. Please go check if the 05 version 
meets your expectation.

Regards,
Remy

From: 6lo [mailto:[email protected]] On Behalf Of sajjad akbar
Sent: Monday, October 22, 2018 7:34 AM
To: Chenlihao (Lihao, IP Technology Research Dept NW) <[email protected]>
Cc: lo <[email protected]>
Subject: Re: [6lo] comments on draft-hou-6lo-plc-04

Hello authors,

The draft is much more clear than its initial version. Good work. I would 
suggest you to clear the discussion about fragmentation. In the current version 
its little confusing, for example you can clearly describe either itstransport 
layer or MAC layer fragmentation. Even if you are not using you can eliminate 
confusing text.

Regards
Sajjad

On Thu, Oct 18, 2018 at 5:47 PM Chenlihao (Lihao, IP Technology Research Dept 
NW) <[email protected]<mailto:[email protected]>> wrote:
Hello authors,

I think this draft gives a good guideline for IPv6 adaptation on PLC. The draft 
has a quite complete description. However, some points need to be clarified. 
Please find my comments below.

- The preface of the section 3 is not well organized. The content of the two 
paragraphs seems to be relevant, but the features of the same PLC technology 
are not in the same paragraph.

- It is reasonable that different PLC technologies have different 
terminologies, but the draft should build up a mapping between them. For 
example, in section 4.3, 1901.1 uses NID and TEI, while 1901.2 uses PAN ID and 
Device ID.

- For Fragmentation and Reassembly, the draft says that “the number of data 
octets of the PHY payload can change dynamically based on channel conditions”, 
thus even for IEEE 1901.1 and 1901.2, the MTU can be lower than 1280 bytes. But 
the second paragraph says that fragmentation and assembly MUST NOT be used. Any 
contradiction here?

- The “charging station to EV communication” use case may not be appropriate 
for using ADOV-RPL in PLC tree network. Since the charging station and the EV 
are directly connected to each other, it should be parent to child 
communication instead of P2P.


Cheers,
Lihao


_______________________________________________
6lo mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6lo
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo

Reply via email to