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

Summary: Needs a YES. Has a DISCUSS. Needs 10 more YES or NO OBJECTION positions to pass.

Barry Leiba Discuss

Discuss (2012-09-17 for -10)
UPDATED FOR -10; I have still not heard from the authors or shepherd for any discussion, so this is just from reading the updated draft.

This is a procedural issue, and note that I'm not expecting a document update for this; I'm expecting a discussion that addresses my questions:

-- Section 3.1 --

   In order to enable transmission of IPv6 packets over BT-LE, a new
   fixed L2CAP channel ID is being 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.  Figure 3 illustrates
   IPv6 over BT-LE stack.  UDP/TCP are provided as examples of a
   transport protocol, but the stack can be used by other transport
   protocols as well.

1. What is the plan for making this request happen?  Should I hold this DISCUSS as a reminder for it to be done?  Or does BT-SIG's process mean that request has to wait until after this document is formally published?  How do we track the allocation, and who is responsible for tracking it? How do implementors know when the allocation is made and what the code point is?  Do we need a reference in the document that someone reading it later can check, which points to wherever they keep their registrations (as we do for IANA assignments)?

2. Does it fit into BT-SIG's procedures to use 0x0007 for now, or are we proposing to "squat" on one of their code points with that recommendation, in a way they would disapprove of?  How are we sure it's OK to use 0x0007?

(Ralph Droms) Yes

(Stewart Bryant) (was Discuss) No Objection

Comment (2012-12-06 for -11)
No email
send info
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?

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2012-07-19 for -08)
No email
send info
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

(Wesley Eddy) No Objection

Comment (2012-07-17 for -08)
No email
send info
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.

(Adrian Farrel) No Objection

Comment (2012-07-19 for -08)
No email
send info
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.

(Stephen Farrell) (was Discuss) No Objection

Comment (2012-10-14 for -11)
No email
send info
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

(Brian Haberman) (was Discuss) No Objection

Comment (2012-08-23 for -09)
No email
send info
Thanks for addressing my DISCUSS points.

(Russ Housley) (was Discuss) No Objection

Comment (2013-03-07)
No email
send info
  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.

(Pete Resnick) No Objection

Comment (2012-07-17 for -08)
No email
send info
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.

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

Comment (2012-07-17 for -08)
No email
send info
In full support of Barry's point on Section 3.1.

(Sean Turner) (was Discuss) No Objection

Comment (2012-07-17 for -09)
No email
send info
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?

Ignas Bagdonas No Record

Deborah Brungard No Record

Alissa Cooper No Record

Roman Danyliw No Record

Benjamin Kaduk No Record

Suresh Krishnan No Record

Warren Kumari No Record

Mirja Kühlewind No Record

Alexey Melnikov No Record

Alvaro Retana No Record

Adam Roach No Record

Martin Vigoureux No Record

Éric Vyncke No Record

Magnus Westerlund No Record