[6lo] Iotdir last call review of draft-ietf-6lo-blemesh-08

Dominique Barthel via Datatracker <noreply@ietf.org> Wed, 28 October 2020 13:31 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6lo@ietf.org
Delivered-To: 6lo@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C62F13A108F; Wed, 28 Oct 2020 06:31:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dominique Barthel via Datatracker <noreply@ietf.org>
To: iot-directorate@ietf.org
Cc: draft-ietf-6lo-blemesh.all@ietf.org, 6lo@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160389187977.20412.7270735327411399214@ietfa.amsl.com>
Reply-To: Dominique Barthel <dominique.barthel@orange.com>
Date: Wed, 28 Oct 2020 06:31:19 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/wUiwJre-yi_TG_W_dfcxBk23B54>
Subject: [6lo] Iotdir last call review of draft-ietf-6lo-blemesh-08
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 28 Oct 2020 13:31:20 -0000

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.