[6lo] Review of draft-wachter-6lo-can-01

[Carles Gomez Montenegro <[e-mail]>]

Dear Alexander,

Thanks for your work on the 6LoCAN draft.

Please find below a review of draft-wachter-6lo-can-01:

- An explicit sentence could be added to the Introduction to explicitly
  state what this document is about (e.g. similar to the last sentence of
  the abstract).

- Sec. 1, 2nd para. "It is a two-wire wired-AND multi-master bus". Perhaps,
  for better readability:  "It is a two-wire, wired-AND, multi-master bus".

- Sec. 1, 2nd para. Expand the CSMA/CR acronym.

- Sec. 1, 2nd para. "arbitration field". Is this a field in the CAN frame
  header? Please give a hint of what this field is, as readers may not be
  familiar with CAN technology.

- Sec. 1, 2nd para. "to identify frames". Should this be to identify the
  source and/or destination of the frames?

- Sec. 1, 2nd para. Expand the CAN-FD acronym.

- Sec. 1, 3rd para. "to support a larger payload is needed". Perhaps, "to
  support a larger payload over CAN" (strictly speaking, perhaps it could be
  better to state larger *than what*).

- Sec. 1, 3rd para. "Mapping addresses to identifiers". Is it CAN addresses?
  (Note that the paragraph starts talking about IPv6.)

- Sec. 1. Expand 6LoCAN on its first use.

- Adding a CAN protocol stack figure (if any is actually defined) and a
  corresponding overview might help clarify the context for this document.

- Adding some other main CAN characteristics (e.g. which is the physical
  layer bit rate) might help understand the need for using 6Lo.

- Adding a protocol stack figure showing how IPv6 is used over CAN would
  help understand how the different pieces in the draft fit altogether.

- Sec. 1.3, 1st para. Did you consider using RFC 8724 for fragmentation? It
  offers 3 fragmentation modes (some of which offering receiver feedback).
  The fragmentation header size in RFC 8724 is not defined as such, but it
  could be small (e.g. 1 byte).

- Sec. 1.3, 2nd para. Does the first sentence refer to classical CAN? If
  yes, please state so.

- Sec. 2, 1st sentence. Please define the concept of a "node address".

- Sec. 2. Add figure callouts for Table 1 and Figure 1.

- Sec. 2, 3rd para. LLDAD could be defined here (first time the expanded
  form is used).

- Sec. 2.1, 2nd sentence. Perhaps better to clarify what type of address we
  are talking about: "The 14-bit link layer destination address" or "The 14-
  bit CAN address".

- Sec. 2.1, 2nd sentence. Expand NDP.

- Sec. 3, 1st sentence. Remove "(LLDAD)", as it should now be defined
  earlier.

- Sec. 3, 2nd para. Expand "DAD", or use LLDAD (if the latter is
  intended).

- Sec. 3, 2nd para. Perhaps "100 ms" instead of "100ms".

- Sec. 4, 2nd para. Please consider RFC 8065.

- Sec. 6, 3rd para. "Network address extension and packet size". Is "packet"
  an "IPv6 packet"? Please clarify.

- Sec. 6.2. What is exactly the meaning of "abort"?  Is there any way for
  the sender to tell the receiver that it is aborting? Is it just silently
  releasing the resources corresponding to the fragmented packet
  transmission? It would be good to clarify a bit what actions are
  carried out by the sender.

- Sec. 7. Should the title be "6LoCAN Frame Format" ?
  (Otherwise, perhaps "frame" might be confused with a "frame" at another
  layer.)

- Sec. 7, 1st sentence. Does "frame" refer to "CAN frame"? Or "6LoCAN
  frame"? Please clarify.

- Sec. 7, 2nd para. "For the first frame". Is this only regarding fragmented
  packet transmission?

- Sec. 7, 2nd para. "in-line header fields" should be "in-line IPv6 header
  fields".

- Sec. 7, 2nd para. "The IPHC and in-line might" should be "The IPHC and in-
  line IPv6 header fields".

- Sec. 7, 2nd para. "The payload data follows" should be "The IPv6 payload
  data follows".

- Is the format in Fig. 14 used only when fragmentation is needed, or is
  there an ISO-TP Header always? (Note that, even if there is only 8 bytes
  of payload in a CAN frame, we should not discard a possible (compressed)
  packet fitting in a single CAN frame.)

- Sec. 8, 4th para, 1st sentence. "the source address": is this a CAN-level
  or an IPv6-level address?

- Sec. 9. This content should be elsewhere in the document (not in Section
  9, as it does not define an action for IANA).

- Sec. 10. Are there security services offered by CAN (e.g. at the link
  layer)? It would be good to explicitly state so (either if the answer is
  "yes" or "no") here.


Cheers,

Carles (as a WG participant)