Dear Tero kivinen. Sorry for the very long late response to your comments.
I appreciate your valuable comments and your comments are very helpful to improve the draft. Based on your comments, I updated the draft and submitted the updated version. Please see my response inlines. Best regards. Yong-Geun. 2021년 3월 2일 (화) 오후 11:04, Tero Kivinen <[email protected]>님이 작성: > In the introduction there is text saying: > > Furthermore, those IEEE 802.15.4 variants do not offer fragmentation > and reassembly functionality. > > This does not take in to account the IEEE Std 802.15.9-2016 > recommended practice which provides multiplexing and fragmentation > layer for the IEEE Std 802.15.4. There is currently ongoing revision > process of that document that will change its from recommended > practice to standard. IEEE Std 802.15.9 is already widely implemented > on some of the environments using IEEE Std 802.15.4, which is the > reason it is upgraded from the recommend practise to standard. > > IEEE Std 802.15.9 fragmentation allows splitting the larger upper > layer frame to multiple fragments. This allows transport of frames > over 24kB of length over the PHY that supports 127 octet frames. > > IEEE Std 802.15.9 also provides multiplexing layer using EtherTypes, > thus it allows running multiple protocols over the same IEEE Std > 802.15.4 network. > > I do understand that IETF has also provide similar features allowing > fragmentation and reassemby of IPv6 packets, but perhaps this document > should also note that in some IEEE Std 802.15.4 networks those might > not be needed, and the methods provided by the IEEE Std 802.15.9 could > also be used. > > The main driver for the IEEE Std 802.15.9 was to provide key > management for IEEE Std 802.15.4, i.e., allow using IEEE Std 802.1X, > HIP, or IKEv2 etc to create keying material for the IEEE Std 802.15.4 > link (there is no guidelines how to use TLS in IEEE Std 802.15.9, as > nobody has shown any interest on that). > > If I remember correctly Wi-SUN is one of those people who do use IEEE > Std 802.15.9. > [Yong-Geun] Thanks for your correction. As you said, we are trying to capture the similar features of 6lo technologies and it is difficult to follow the latest information of IEEE 802.15.9. I downloaded the specification of IEEE 802.15.9 and checked the feature that you pointed out. I added a sentence that describes this situation in the Introduction part. > As a nit, the proper way to refer to the IEEE Standards is to use > "IEEE Std 802.15.4" or "IEEE Std 1901-2010" if dated version is > needed. Note the "Std" between the IEEE and the standard number, and > that there is no "." after the Std. There is several references to > "IEEE 802.15.4", or "IEEE 1901-2010" etc in the RFC. Also in the > normative referneces there is version which have "Std." instead of > "Std". > [Yong-Geun] Thanks for your correction. I checked the expressions and updated them with your points. > Normative references also has old title for IEEE Std 802.15.4. The > title used there was changed in 2011 to "Part 15.4: Low-Rate Wireless > Personal Area Networks (LR-WPANs)", then simplified in 2015 to "IEEE > Standard for Low-Rate Wireless Personal Area Networks (WPANs)" and > simplified again in 2020 to "IEEE Standard for Low‐Rate Wireless > Networks". I did not check whether the IEEE Std 1901 standard names > are correct. > [Yong-Geun] I checked the IEEE Std 802.15.4 document and updated the title with the latest information. And I also checked the IEEE Std 1901, IEEE Std 1901.1, IEEE Std 1901.2 and there are no errors. > Also refering to the dated references (like "802.15.4-2006") or > specific amendments (like "802.15.4g") is always problematic, > especially as the underlaying standards evolve, and the groups start > using newer versions when they publish new revisions of their draft. > Refering to specific amendment where there is already new revision > out, is like refering to the specific RFC even when it is already > obsoleted by the newer one. When there is new revision that includes > all amendments published prior the revision, thus there is no longer > any need to refer any amendments separately, you should always refer > to the revision instead. > > For example I am not sure current Thread group uses IEEE Std > 802.15.4-2006 anymore, i.e., any features that were there in 2006, but > which are no longer in newer versions (i.e., features which were > deprecated). Thread 1.2 white paper talks only about IEEE > 802.15.4-2015, which was the latest version when that whitepaper was > written (2019), but I think Thread group did provide some comments > during the IEEE Std 802.15.4-2020 revision process, so they might have > moved to latest version already. > > Anyways providing such level of details is unnecessarely and might be > misleading when those external standards evolve, so I would recommend > removing that kind of version specific details. [Yong-Geun] I agree with your point. I removed that sentence. > > -- > [email protected] >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
