Transmission of IPv6 Packets over BLUETOOTH Low Energy
draft-ietf-6lowpan-btle-12

On the whole, I am supportive of this document, and there are enough
Discusses covering the main issues. Please consider my Comments some of
shich may help resolve those Discusses.

---

I am a little confused about the difference between "Bluetooth 4.0" and
"BT-LE."

The Abstract adds to this confusion...

   The low power variant of Bluetooth is
   commonly specified in revision 4.0 of the Bluetooth specifications
   and commonly refered to as Bluetooth 4.0.

1. s/commonly specified/currently specified/  ?

2. Is the low power version of Bluetooth commonly refered to as 
   Bluetooth 4.0 as the text appears to say? If so, why do you 
   consistently refer to BT-LE instead? 

Section 2, on the other hand, suggests that BT-LE is only a part (albeit
integral) of the Bluetooth 4.0 spec.

---

I see no reason to refer to the "Bluetooth Smart" and "Bluetooth Smart
Ready" trade names. Only one is used in the document, and could easily
be replaced with real text. Cleaning this up would avoid the issues of:
- a reference that is a URL and not a pointer to a document
- the whole trademark issue

---

Section 2.3

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

Asphrased, this implies that you are changing the BT 4.0 spec (which is
not your intention and would not go down well!). I think what you mean
is:

   This specification mandates that Bluetooth devices transmitting IPv6
   packets in conformance with this specification MUST use a Bluetooth
   Device Address that is a public address.

---

Section 3.1 and Section 4

I do not think this document should attempt to specify (or discuss) code
points that will be allocated by other bodies.

I'll trust the ADs who reported the DISCUSSes to solve the issues. Note that I'll have a closer look at the next version

Thanks for addressing my DISCUSS points.

In full support of Barry's point on Section 3.1.

Section 2 is generally an overview of BT-LE. I'm not a big fan of doing technology overviews in specifications; I say just get to the protocol and give a reference or appendix for overviews.

That said, I worry that there are 4 MUST/MUST NOT requirements in 2.3 and 2.4. If people see section 2 as purely overview, they may miss these requirements. I'd suggest moving the requirements into section 3 (the specification) to make sure that nobody misses them.

  I selected two portions of the Gen-ART Review from Brian Carpenter
  that meet the DISCUSS Criteria.  One was resolved.  The other remains
  a problem, but it is covered by the DISCUSS position entered by Barry.
  I am going to let Barry hold the DISCUSS position to make sure that
  the remaining concern is resolved.  Section 3.1 includes this paragraph:

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

  Let's wait for needed L2CAP Channel ID to be allocated, and then
  publish a standards-track RFC.

1) I support Adrian's discuss.

2) I liked Pete's suggestions too.

3) typos the secdir reviewer noted:

  gateway^1s => gateway's
  respectively => respectively

5) s5: Any chance for specific references to were the BT-LE LL security and SMP are defined?  Is it part of the core?

Version -11 addressed my discuss. I didn't check the comments
but let me know if I ought.

- The "MUST be reserved by the BT-SIG" in 3.1 is odd. Why
haven't they already? Is this text meant to go into the RFC
or not?  I'd hope not and that we'd hold the RFC until
they've allocated an ID for us.  So I agree with Barry's
discuss on this.

- Shouldn't you provide a reference to where you can go see
the BT-SIG allocation? I did go looking for a few minutes and
its non trivial to find. (In a few minutes:-) 

- Is the channel ID in 3.1 for IPv6 of all kinds, or only for
IPv6 as discussed in this spec? I think that needs to be
clear in this spec. 

- The text describing Figure 3 might be better to say that
TCP & UDP are just examples.

- 3.2.1: says "MUST NOT use more than one IID" - presumably
that means at a given moment? When is it ok to change?

- End of 3.2.1: s/draft/specification/

- 3.2.3: Is "elided" clear enough? I guess it might be if
you're familiar with 6lowpan, but if not maybe more's needed.
Maybe give a reference to where how to do that is defined.

- 3.2.3: Is "global IPv6 address" right there? Couldn't it be
some other special kind of address?

- nits via secdir review:-)

gateway^1s => gateway's
respectively => respectively

Bluetooth Special
   Interest Group [BT-SIG] has introduced two trademarks, Bluetooth
   Smart for single-mode devices (a device that only supports BT-LE) and
   Bluetooth Smart Ready for dual-mode devices.

If these are trademarks, as opposed to device class names, have we represented the trademarked name in the legally accepted format? Do we need to represent "Bluetooth" in a format to identify it as a trademark term?

Figure 3 seems to suggest that TCP or UDP are the only supported transports, and that there are no applications above them, or other tunneling possible.  I think the figure should just show a generic "upper layer protocols" blob on top of IPv6, or just end the stack at IPv6 unless the capability is really restricted to just TCP and UDP, no ICMPv6, etc., which doesn't seem right.