[Gen-art] Gen-art LC review of draft-ietf-6lo-btle-13

[Elwyn Davies <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-6lo-btle-13.txt
Reviewer: Elwyn Davies
Review Date: 2015/06/01
IETF LC End Date: 2015/06/09
IESG Telechat date: (if known) -

Summary:

Major issues:

Minor issues:
s2.2:  As I read this section, it seems to imply (but doesn't make it 
totally clear) that a peripheral would only connect to a single central 
over IPv6 at a time.  Is this true?  Mesh networking being out of scope 
would appear to be another issue that would not necessarily preclude a 
peripheral from having multiple interfaces to different centrals - 
provided it was capable of handling the multiple interfaces - but would 
not need to act as a router.  OK, this might not be something that would 
be an everyday event in the IoT but it would be good to make it clear 
what the specification implies in this area.

s3.2, para 5:  [This is just fractionally more than editorial]  The 
selection of the multilink subnet model is important and deserves a 
(sub-sub-)section to itself.  I suggest moving the second and subsequent 
sentences of para 5 of s3.2 to a new s3.2.1 and renumbering the 
remaining sub-sub-sections, thus:
OLD:
    Bluetooth LE connections used to build a star topology are point-to-
    point in nature, as Bluetooth broadcast features are not used for
    IPv6 over Bluetooth LE (except for discovery of nodes supporting
    IPSS).  As the IPv6 over Bluetooth LE is intended for constrained
    nodes, and for Internet of Things use cases and environments,
    multilink model's benefits are considered to overweight multilink
    model's drawbacks described in RFC 4903 [RFC4903].  Hence a multilink
    model has been chosen, as further illustrated in Section 3.3.
    Because of this, link-local multicast communications can happen only
    within a single Bluetooth LE connection, and thus 6LN-to-6LN
    communications using link-local addresses are not possible. 6LNs
    connected to the same 6LBR has to communicate with each other by
    using the shared prefix used on the subnet.  The 6LBR ensures address
    collisions do not occur (see Section 3.2.2) and forwards packets sent
    by one 6LN to another.

    After the peripheral and central have connected at the Bluetooth LE
    level, the link can be considered up and IPv6 address configuration
    and transmission can begin.

3.2.1.  Stateless address autoconfiguration
...
NEW:
    Bluetooth LE connections used to build a star topology are point-to-
    point in nature, as Bluetooth broadcast features are not used for
    IPv6 over Bluetooth LE (except for discovery of nodes supporting
    IPSS).
    After the peripheral and central have connected at the Bluetooth LE
    level, the link can be considered up and IPv6 address configuration
    and transmission can begin.

3.2.1. IPv6 Subnet Model

    In the Bluetooth LE piconet model (see Section 2.2) peripherals each
    have a separate link to the central and the central acts as an IPv6
    router rather than a link layer switch.  As discussed in [RFC4903],
    conventional usage of IPv6 anticipates IPv6 subnets spanning a single
    link at the link layer.  As IPv6 over Bluetooth LE is intended for 
constrained
    nodes, and for Internet of Things use cases and environments, the
    complexity of implementing a separate subnet on each peripheral-central
    link and routing between the subnets appears to be excessive.  In the
    Bluetooth LE case, the benefits of treating the collection of 
point-to-point
    links between a central and its connected peripherals as a single 
multilink
    subnet rather than a multiplicity of separate subnets are considered to
    outweigh the multilink model's drawbacks as described in RFC 4903 
[RFC4903].

    Hence a multilink model has been chosen, as further illustrated in 
Section 3.3.
    Because of this, link-local multicast communications can happen only
    within a single Bluetooth LE connection, and thus 6LN-to-6LN
    communications using link-local addresses are not possible. 6LNs
    connected to the same 6LBR have to communicate with each other by
    using the shared prefix used on the subnet.  The 6LBR ensures address
    collisions do not occur (see Section 3.2.3) and forwards packets sent
    by one 6LN to another.

3.2.2.  Stateless address autoconfiguration
....
END




Nits/editorial comments:
General: Prefer 'octet' to 'byte'.

General: Consistent use of 'link layer' or 'link-layer' - both are used 
in a somewhat aribitrary fashion.

Abstract: s/is standardized since the revision/has been standardized 
since revision/

Abstract:  The 6LoWPAN acronym needs to be expanded.

s1: To be consistent with the abstract it would be best if the 
connection (equivalence) between Bluetooth Smart and Bluetooth LE was 
reiterated in the first sentence and noted that Bluetooth LE is used in 
the rest of the document.

s1, para 1: To avoid jargon s/coin cell/very low capacity (e.g., "coin 
cell")/

s1, para 2: Suggest s/ideal protocol/ideal protocol for communication 
with such devices/  to make it clear what it is ideal for.

s1, para 3: 802.15.4 needs a reference.  Should this be to the updated 
2011 version ( RFC 4944 refers to the 2003 standard)?
IEEE Computer Society, "IEEE Std. 802.15.4-2011 IEEE Standard for Local 
and metropolitan area networks--
Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)", June 2011.

s1, para 3:  The general connection to 6LoWPAN mentioned in the last 
sentence of the Abstract ought to be repeated at the start of para 3;
OLD:
    RFCs 4944, 6282, and 6775 [RFC4944][RFC6282][RFC6775] specify the
    transmission of IPv6 over IEEE 802.15.4.
NEW:
    This document describes how IPv6 is transported over Bluetooth Smart 
(also known as
    Bluetooth LE) low power connections using IPv6 over Low power 
Wireless Personal Area
    Networks (6LoWPAN) techniques.  RFCs 4944, 6282, and 6775 
[RFC4944][RFC6282][RFC6775]
    developed for 6LoWPAN specify the transmission of IPv6 over IEEE 
802.15.4.
END

s1.1, para 2: Please include the expansions of the acronyms 6LN, 6LR and 
6LBR here.

s2, para 1:
>     Bluetooth LE is designed for transferring small amounts of data
>     infrequently at modest data rates at a very low cost per bit.
Presumably this is energy cost?   Maybe better:
s/at a very low cost/with a very small energy expenditure/

s2, para 2: s/published/published the/,
                     s/includes/includes the/,
                     s/link-layer/a link-layer/

s2, para 2: To be clear 'newer' (presumably) applies to both BT 4.1 and 
IPSP 1.0:
s/newer/more recent versions of either specification to provide 
necessary capabilities/

s2, para 3:
OLD:
which will include Bluetooth 4.1 chipsets
NEW:
that incorporate chipsets implementing Bluetooth 4.1 or later
END

s2, para 3:  The standard cannot guarantee presences of Bluetooth LE:
s/will also be included/is also expected to be included/

s2.1, para 1:
> The device internal Host Controller Interface (HCI)
I don't think the qualifier 'device internal' really helps here and 
could be usefully omitted.
The nature of the interface is explained in the following text.

s2.2, para 1: 'but since Bluetooth 4.1' is a bit ambiguous.  After some 
thought, I assume it is supposed to mean that the capability to connect 
to multiple centrals at once started only with BT 4.1.  How about:
OLD:
but since Bluetooth 4.1 can also connect to multiple centrals.
NEW:
but with versions of Bluetooth from 4.1 onwards it can also connect to 
multiple centrals at the same time.
END

s2.2, para 1: s/i.e. a Bluetooth/i.e., a Bluetooth/

s2.3, para 1:  Hope the device isn't running on AC!!
OLD:
This typically happens at every power cycle of a device.
NEW:
New addresses are typically generated each time a device is powered on.
END

s2.4, title: s/packets sizes/packet sizes/

s2.4: s/Optimal/The optimal/,
          s/Default MTU/The default MTU/,
          s/exclusing L2CAP/excluding the L2CAP/,
          s/protocol data/a protocol data/,
          s/link layer fragmentation/a link layer fragmentation/,
          s/provides MTU/provides an MTU/
          s/single link-layer MTU value/an equal link layer MTU for the 
two directions/

s3, para 1: s/due Bluetooth LE's/due to Bluetooth LE's/

s3, para 2: s/both star and mesh topology/both star and mesh topologies/,
                    s/inter- peripheral/inter-peripheral/ [Space removed]

s3, para 4: s/Bluetooth SIG/the Bluetooth SIG/

s3, last sentence:  This duplicates the statement made in s2 (subject to 
the mod proposed above).  It could be omitted.  However, if repeating it 
is thought worthwhile, it might be better right at the start of s3.

s3.1: s/IPv6 stack/the IPv6 stack/,
          s/GATT stack/the GATT stack/,
         s/Bluetooth LE/the Bluetooth LE/,
         s/GATT/The GATT/
         s/Internet/The Internet/

s3.2, para 1: s/The concept of/The distinct concepts of the/, 
s/needs/need/, s/the relationship/their relationship/

s3.2, para 2: s/6LoWPAN/the 6LoWPAN/,
                       s/use of 1280 byte/use of a 1280 byte [octet] MTU/