Hi Kiran, (Adding the LPWAN and SCHC WGs in CC'.)
First of all, apologies for the radio silence, and many thanks for your valuable questions, comments and suggestions. Please find inline responses, below: On Thu, 18 May 2023 at 17:10, Kiran Makhijani <kiran...@gmail.com> wrote: > Hello authors, > Apologies for late comments. May be we can talk about the detailed review > later, instead I wanted to discuss high-level points first. Please take > them as comments from a newbie... > > 1. I found it bit challenging to catch up with all the past 4-digit > RFC-soup that this document need to reference (3 from SCHC, 3 from base > 6lowPAN, a few on RPL). It becomes arduous to follow everything (I had to > read 4 to 5 documents before getting reasonable understanding on how I > could help with review). I am not sure how can this be addressed but > something to consider as a broader assumption when writing the document. > > Thanks for the comment. We hear you, and will try to keep your comment in mind. However, the nature of this document (which in its current form is based on mechanisms created by at least 3 different WGs) makes it difficult to simplify the amount of background required. > 2. One suggestion is to re-write architecture section. > 2.1. Since 6lowPAN is using SCHC, I find it odd that it does not talk > about adapting SCHC architecture in LLN. i.e. say what node will need to > support what SCHC functionality. Then the document will become easier to > read. For instance, you could draw a LLN with 6LRs, BRs etc. and say what > SCHC gateway functionality will fit where instead of saying in > straight-forward RPL rules should be installed in all LRs... > 2.2 So I suggest first present both the architecture then map > functions will be better and then develop cases. > These are very good suggestions. While the information is (hopefully) available in the document in sections 3.2 and 3.3, it can probably be presented more clearly, as you suggest. > 2.3 Ques: how are SCHC rules distributed in LPWAN? > This is still being discussed at the LWPWAN/SCHC WGs. :-) The straightforward approach is a completely a priori distribution of SCHC Rules. However, there may be other options. Some related work is on the agenda of the joint LPWAN/SCHC meeting at IETF 117. > Can same techniques be used or RPL is the only approach? (sorry, I am not > finished reading SCHC and don’t know this yet). > > If you refer to the route-over multihop approaches, there are currently three, with only one of them (the Tunneled, RPL-based Route-Over approach) requiring the use of RPL. > 3. I would have really liked to see 'SCHC dispatch' discussed earlier as > part of the architecture instead of dealing with it later. This is a key > LLN dataplane enhancement and everything builds on top of it. The key is > you are not adding new rules, you are using LLN data plane to carry SCHC > and nodes with knowledge of this feature will process accordingly. > > Yes, you are right that the first mention of the 'SCHC Dispatch' is a bit obscure (it appears in section 3.3.3). We can follow your suggestion and introduce it earlier in the architecture section. > To summarize, when you put this together, reading of document will be very > simple: > - adapt SCHC architecture > - describe new dataplane enhancement > - describe routing mechanisms > - formats... > > What do you think? It's possible I must have misunderstood, in that case > please bear with my ignorance :-). > On the contrary, many thanks for your constructive feedback and suggestions, which we will fully consider for -03. Cheers, Carles (as WG participant) > Thanks > Kiran > > _______________________________________________ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo >
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
