Telechat Review of draft-ietf-6lowpan-btle-

Request Review of draft-ietf-6lowpan-btle
Requested rev. no specific revision (document currently at 12)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-07-17
Requested 2012-07-12
Authors Johanna Nieminen, Teemu Savolainen, Markus Isomaki, Basavaraj Patil, Zach Shelby, Carles Gomez
Draft last updated 2012-07-15
Completed reviews Genart Last Call review of -?? by Brian Carpenter
Genart Telechat review of -?? by Brian Carpenter
Secdir Last Call review of -?? by Steve Hanna
Assignment Reviewer Brian Carpenter 
State Completed
Review review-ietf-6lowpan-btle-genart-telechat-carpenter-2012-07-15
Review result Almost Ready
Review completed: 2012-07-15


Please see attached review.

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

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-6lowpan-btle-08.txt
Reviewer: Brian Carpenter
Review Date: 2012-07-17
IETF LC End Date: 2012-07-11
IESG Telechat date: 2012-07-19

Summary:  Almost ready


No feedback received to LC review, so these comments have not changed.

The document is very clear and easy to understand. My issues are
definitely not fundamental.

Major issues:

Section 3:

"BT-LE technology sets strict requirements for low power consumption
and thus limits the allowed protocol overhead. 6LoWPAN standards
[RFC4944], [I-D.ietf-6lowpan-nd] and [RFC6282] provide useful generic
functionality like header compression, link-local IPv6 addresses,
Neighbor Discovery and stateless IP-address autoconfiguration for
reducing the overhead in 802.15.4 networks.  This functionality can
be partly applied to BT-LE."

This is unclear. The three references are normative but only "partly applied".
An implementer needs to know *exactly* which parts of the references are
normative. For example you could add something here like "Precise details of
the functionality applied to BT-LE are given in this document, and other parts 
of these references are not applicable to BT-LE." Sections 3.2.2 and 3.2.3 are 
reasonably detailed for [I-D.ietf-6lowpan-nd] and [RFC6282], although it
would be good to give references to section numbers. However, very little is
explained for [RFC4944].

Section 3.1:

"In order to enable transmission of IPv6 packets over BT-LE, a new
fixed L2CAP channel ID MUST be reserved for IPv6 traffic by the BT-
SIG.  A request for allocation of a new fixed channel ID for IPv6
traffic by the BT-SIG should be submitted through the liaison process
or formal communique from the 6lowpan chairs and respective area
directors.  Until a channel ID is allocated by BT-SIG, the channel ID
0x0007 is recommended for experimentation.  Once the channel ID is
allocated, the allocated value MUST be used."

This is a very clumsy situation to leave in a standards track RFC. 
It does not state who must submit the allocation request; this should
be made definite. But it would be much better to get the allocation
*before* the RFC is published, as we would for an IANA allocation.
Otherwise the risk that products ship with 0x0007 built in is very high.

Minor issues:

Section 2.3:

"This specification mandates that the Bluetooth Device Address MUST be a public address."

Why? As long as the U bit is set correctly, a non-universal MAC address is acceptable
in IPv6. (Also affects section 3.2.1.)

Section 2.4:

"An inherent function of the BT-LE
L2CAP layer, called Fragmentation and Recombination (FAR), can assist
in transferring IPv6 packets that do not fit in a single BT-LE data
channel PDU."

That implies that some IPv6 packets do fit in a single channel PDU, which
is impossible without compression. You discuss compression later but it should
be mentioned here for clarity. s/IPv6 packets/compressed IPv6 packets/

Section 3:

"In addition, a BT-LE device MUST NOT play the role of a 6LoWPAN
Router (6LR)."

Just for clarity: remind that the BT-LE Master may be a 6BLR, which is a sort
of exception to this rule.

"Appendix A.  Bluetooth Low Energy fragmentation and L2CAP Modes"

This is so short that it could perhaps be included in the main text.