Telechat Review of draft-ietf-6lo-rfc6775-update-11
review-ietf-6lo-rfc6775-update-11-opsdir-telechat-schoenwaelder-2018-02-21-00

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?