As an outsider, I would also have preferred to see the message formats before reading the details how protocol entities have to use the message fields and react to messages received. But this may be personal preference. Overall, I found the text to be clear, except where noted below. From an operational point of view, I wonder whether there is work planned to enable the network administrator to monitor registrations and to identify routers that run out of registration capacity or to detect high numbers of failing registrations (which could have technical reasons but could also be caused by malicious activity). The text says network administrators should make sure there is sufficient registration capacity but without any way to monitor usage of registration capacity, this may be difficult to achieve in environments where the network administrator has not control over devices getting deployed. Section 2: - What is the 'legacy 6LoWPAN ND specification'? I found out later that legacy is a defined term in Section 3. Perhaps it makes sense to first define the terminology, i.e., swapping sections 2 and 3. - 'With this specification, a failed or useless registration can be detected...' - detected by whom? The entity registering or the entity managing the registrations? - There is advice that network administrators should deploy 6LR/6LBRs matching the number and type of devices. Since it is usually difficult to know how many registrations a network will require, is there a way to find out when the 6LR/6LBRs run out of capacity or is there a way to monitor the usage of the registration capacity? Section 3: - The phrase 'to be a higher speed device speed' is odd; note that you are actually talking about a link and its datarate. Section 4: - Note sure I understand the sentence that includes 'is be saturated'. I guess you mean: If the registry in the 6LBR is saturated, then the LBR cannot decide whether a new address is a duplicate. But perhaps I have not understood the situation really. I understand that once saturated, registration requests are denied. Perhaps all you wanted to say is this: If the registry in the 6LBR is saturated, then the LBR replies to a EDAR message with a EDAC message that carries a Status code 9 indicating "6LBR Registry saturated", Section 5: - s/is a used as a/is used as a/ Section 7: - Is there a verb missing in the first sentence of 7.1.2? - s/in a registration flows/in a registration flow/ Section 8: - RFC 6775 is not really a 'draft' - s/requesting a node the/requesting node the/ - I wonder to what extend the expectation that the underlying network provides secure unicast and multicast services and that there is a trust model in place that ensures that only the right devices act as 6LBR and 6BBR is wishful thinking. Should the document more clearly spell out how fragile things will be if this is not the case? Should the document provide concrete pointers how to satisfy these requirements? I know, this is a nasty question but deploying this technology without proper protection sounds like a real problem. Anyway, this is probably for the secdir reviewers to think about. Section 9: - s/section Section/Section/ - Should there be any discussion of the possibility to monitor movements? Should a device actually claim a different identity when moving?