Please see attached review.



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-6lowpan-btle-08.txt
Reviewer: Brian Carpenter
Review Date: 2012-07-03
IETF LC End Date: 2012-07-11
IESG Telechat date: 

Summary:  Almost ready
--------

Comment:
--------

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.