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

Carles Gomez Montenegro <carlesgo@entel.upc.edu> Thu, 04 June 2020 09:12 UTC

Return-Path: <carlesgo@entel.upc.edu>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4164C3A0A90 for <6lo@ietfa.amsl.com>; Thu, 4 Jun 2020 02:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6aEOrKSBxDRE for <6lo@ietfa.amsl.com>; Thu, 4 Jun 2020 02:12:29 -0700 (PDT)
Received: from violet.upc.es (violet.upc.es []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B013A0A7E for <6lo@ietf.org>; Thu, 4 Jun 2020 02:12:28 -0700 (PDT)
Received: from entelserver.upc.edu (entelserver.upc.es []) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 0549CQCV044346; Thu, 4 Jun 2020 11:12:26 +0200
Received: from webmail.entel.upc.edu (webmail.entel.upc.edu []) by entelserver.upc.edu (Postfix) with ESMTP id B01D21D53C1; Thu, 4 Jun 2020 11:12:26 +0200 (CEST)
Received: from by webmail.entel.upc.edu with HTTP; Thu, 4 Jun 2020 11:12:26 +0200
Message-ID: <67a82de3fbf2208ef203ad8d5fb54d60.squirrel@webmail.entel.upc.edu>
Date: Thu, 4 Jun 2020 11:12:26 +0200
From: "Carles Gomez Montenegro" <carlesgo@entel.upc.edu>
To: alexander@wachter.cloud
Cc: 6lo@ietf.org
User-Agent: SquirrelMail/1.4.21-1.fc14
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.100.3 at violet
X-Virus-Status: Clean
X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (violet.upc.es []); Thu, 04 Jun 2020 11:12:27 +0200 (CEST)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/J6YqlLcqHRN1wGKXHHfu9aAks6s>
Subject: [6lo] Review of draft-wachter-6lo-can-01
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jun 2020 09:12:31 -0000

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

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

- 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

- 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

- 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.


Carles (as a WG participant)