Reviewer: Dominique Barthel Review result: Ready with Nits Thanks for this useful and timely draft. I found it ready for publication, but for a few questions/comments, and a few nits. Questions 1. RFC 2119 is referenced. Shouln't RFC 8174 be referenced as well? 2. Section 3.3.2 states "Note that in some cases (e.g. very short-lived connections) it may not be worthwhile for a 6LN to send an NS with EARO for registering its address". It would be useful to describe the consequences of not registering the address. What about reachability from the other end, in case a response is expected? DAD? 3. Section 3.3.2 states "If the 6LN registers multiple addresses that are not based on Bluetooth device address using the same compression context, the header compression efficiency will decrease". I found this sentence difficult to parse. It seems to summarize considerations developped in Section 3.2.4 of RFC7668. If this is true, a reference to that section would help the reader. Checking the details of Section 3.2.4 of RFC7668, I realized that I had not fully understood it yet. Even though it is a long-published RFC, can you educate me on why the address last registered with the ARO gets a better compression than other addresses that share the same prefix? For example, see "and if SAC=1 and SAM=11, the 6LN MUST have registered the source IPv6 address with the prefix related to the compression context, and the 6LN MUST be referring to the latest registered address related to the compression context". Does it imply that the ARO modifies the 6282 compression context at the 6LR? How does the ARO relate to the compression context? A related, and striking, sentence in RFC7668 is "The 6LN can register a new address, or re-register an expired address, to become able to again fully elide an address", seemingly implying a connection between registration and compression. Please advise. 4. Section 3.3.3 states "Note that 6CO is not needed for context-based compression when a single prefix is used in the network". Can you please explain how you do context-based compression without loading the context via a 6CO? Do you assume the context is pre-provisioned via some out-of-band means? If yes, how is it specific to the case where a single prefix is used in the network? If no, is it because some registration/compression connection that I missed (see comment #3)? RFC 7668 has a MUST instead of a MAY in the sentence "To enable efficient header compression, when the 6LBR sends a Router Advertisement it MAY include a 6LoWPAN Context Option (6CO) [RFC6775] matching each address prefix advertised via a Prefix Information Option (PIO) [RFC4861] for use in stateless address autoconfiguration". Is this a short sighting of RFC7668, that would be worth an update? Or is the MAY specific to the mesh version of BLE networks? 5. Section 3.3.3 states "These cases comprise link-local interactions, non-link-local packet transmissions originated by a 6LN, and non-link-local packets intended for a 6LN that are originated or forwarded by a neighbor of that 6LN". Pretending for a moment that I undestood compression as specified per RFC 7668, do I understand correctly that, in the BLE mesh, 7668-like compression only applies to the first hop from a 6LN or to the last hop toward a 6LN, and that any hop beyond that cannot use 7668-like compression? Would this be a better text to replace the one I just quoted? Nits: - 3.3.2: "For sending Router Solicitations and processing Router Advertisements the Bluetooth LE hosts MUST, respectively, follow ..." There is no such thing as a BLE host in the Terminology. Do you mean "IPSP Node" or "IPv6 host that participates in the BLE mesh"? - 3.3.2: "A 6LBR uses the IPSP Router role since the 6LBR is initialized". What does "is initialized" specifically mean, in this sentence? The 6LN and 6LR are also initialized at startup, but I guess they lack the state that you assume is preconfigured in the 6LBR. - 3.3.2: "See an example in the Appendix" --> "See an example in Appendix B" - Appendix A is not referenced anywhere in the body of the document. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
