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

[Ballot comment]

  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.

[Ballot comment]
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?

[Ballot comment]

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

[Ballot discuss]
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?

[Ballot discuss]
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?

[Ballot discuss]
-10 doesn't answer my question, which I think would be best
handled via a mail explaining why this choice was made.

In figure 5 the 6LBR is the BTLE-Master and the gateway to
the Internet, which is a reasonable choice, but why is it the
only choice? Are there no scenarios where a BT-LE slave
wouldn't have another i/f and so be able to act as a g/w to
the Internet, e.g. when the BTLE-Master doesn't have an
Internet connection? Why rule that out? There may well be
good reasons but it wasn't clear to me.

I guess another way to ask this is to ask why you can't
support this diagram:

              h                ____________
              \              /            \
        h ---- Master -- h -- |  Internet  |
              /              \____________/
              h

[Ballot discuss]
-09 doesn't answer my question, which I think would be best
handled via a mail explaining why this choice was made.

In figure 5 the 6LBR is the BTLE-Master and the gateway to
the Internet, which is a reasonable choice, but why is it the
only choice? Are there no scenarios where a BT-LE slave
wouldn't have another i/f and so be able to act as a g/w to
the Internet, e.g. when the BTLE-Master doesn't have an
Internet connection? Why rule that out? There may well be
good reasons but it wasn't clear to me.

I guess another way to ask this is to ask why you can't
support this diagram:

              h                ____________
              \              /            \
        h ---- Master -- h -- |  Internet  |
              /              \____________/
              h

[Ballot comment]
- 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

[Ballot discuss]
UPDATED FOR -09; I have not heard from the authors or shepherd for any discussion, so this is just from reading the updated draft.

This is a procedural issue:
-- 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.

1. The first MUST is inappropriate: we don't have any standing to make a normative requirement on the BT-SIG.  What you *mean*, I think, is simply that we have to get a channel ID allocation (a demand on the 6lowpan chairs, I guess, to handle that), and then we MUST use it (the second MUST covers that part).

UPDATE: *** This point appears to be resolved in -09 ***

2. Has this request been made?  If so, what is its status (neither the document nor the shepherd writeup says)?  If not, when is that planned to happen?  Should I hold this DISCUSS as a reminder for it to be done?  Or does that request have to wait until after this document is published (in which case, how do we track it)?

UPDATE: *** This point appears to remain in -09 ***
By saying "is being allocated", we have an implication that the request has been made.  But the subsequent text still talks about "a request ... should be submitted", so I'm not sure.

And there remains the question of how we track the allocation, and how implementors know when the allocation is made and what the code point is.  Maybe we need a reference in the document that someone reading it later can check, which points to wherever they keep their registrations.

3. 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?

UPDATE: *** This point appears to remain in -09 ***
No one has answered this question.

[Ballot comment]
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.

[Ballot discuss]
I support the publication of this document, but there are some issues that need to be DISCUSSed...

1. This is probably related to Stephen's DISCUSS on which types of nodes can act as Internet gateways. The second paragraph of Section 3 says that BT-LE does not support the formation of multihop networks.  I assume this is implying multihop at the Bluetooth layer and not the IP layer since the spec later talks about forwarding IPv6 packets between master nodes. This should be stated more clearly in the text.  As a follow-on, does this multihop limitation also mean that slave nodes can only have a single interface (thus eliminating Stephen's alternative gateway location architecture)?

2. Section 3.2.1 states that IPv6 over BT-LE will perform SLAAC as defined in RFC 4862.  Given the limited topology of BT-LE, is there a reason to perform all of 4862?  Since section 3.2.2 requires a node to register its address with the master, is there a need to perform DAD on the point-to-point link between the master and slave?  The 802.15.4 spec needs that capability because of the potential to operate in a mesh topology, but it really isn't needed in the star topology.

3. Related to Sean's DISCUSS on header compression... The opening sentence of section 3.2.3 does not make sense.  Why does it say "This document assumes [RFC6282]..."?  As a protocol specification, it specifies what is to be used.  Something along the lines of "Header compression, as defined in RFC 6282 is REQUIRED..." would be more appropriate.

[Ballot comment]
1. The Abstract can be dramatically condensed.  I don't see a reason to spend time in this section discussing the differences between BT-LE and base Bluetooth.

2. I agree with Russ' DISCUSS point about the abstract nature of the first paragraph in Section 3.  This spec needs to explicitly indicate which parts of the referenced specs apply to each of the mentioned technology areas.

3. Section 3.2.1 says that a node SHOULD use its EUI-64 for SLAAC.  Is there a scenario you can provide in the draft as an example where that SHOULD can be ignored?  RFC 3041 addresses come to mind.

4. The discussion of DHCPv6 Prefix Delegation should include an Informative reference to RFC 3633.

5. Figure 4 really adds nothing to the document since the link-local address format is not changed from what is in RFC 4291.

[Ballot discuss]
  I have selected portions of the Gen-ART Review from Brian Carpenter
  that meet the DISCUSS Criteria.  From my perspective, it would have
  been much simpler for the authors to respond to these comments when
  they were first posted during IETF Last Call.

  (1) 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.

  (2) Section 3 includes this paragraph:

  "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 not the Introduction section, when an unclear statement like
  this might be acceptable.  Three normative references are provided,
  but we are told that they are "partly applied".  An implementer is not
  given enough information to build interoperable implementations.
  Brian suggested text; however, I would strongly prefer a pointer to
  a subsection for each normative reference.

[Ballot discuss]
So this is probably a lame discuss, but I can't figure it out.  In s3.2.3, you say "all headers MUST be compressed according to HC base encoding".  But, in RFC 6282 there's IPHC, HNC, and IPv6 Header Encoding.  Which one is the HC base encoding?  Is it the one in s3.2.1 (IPv6 HE), which is referenced later in the section?

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
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?

=======

[Ballot discuss]

In figure 5 the 6LBR is the BTLE-Master and the gateway to
the Internet, which is a reasonable choice, but why is it the
only choice? Are there no scenarios where a BT-LE slave
wouldn't have another i/f and so be able to act as a g/w to
the Internet, e.g. when the BTLE-Master doesn't have an
Internet connection? Why rule that out? There may well be
good reasons but it wasn't clear to me.

I guess another way to ask this is to ask why you can't
support this diagram:

              h                ____________
              \              /            \
        h ---- Master -- h -- |  Internet  |
              /              \____________/
              h

[Ballot comment]

- 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

[Ballot discuss]
This is a procedural issue:
-- 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.

1. The first MUST is inappropriate: we don't have any standing to make a normative requirement on the BT-SIG.  What you *mean*, I think, is simply that we have to get a channel ID allocation (a demand on the 6lowpan chairs, I guess, to handle that), and then we MUST use it (the second MUST covers that part).

2. Has this request been made?  If so, what is its status (neither the document nor the shepherd writeup says)?  If not, when is that planned to happen?  Should I hold this DISCUSS as a reminder for it to be done?  Or does that request have to wait until after this document is published (in which case, how do we track it)?

3. 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?

[Ballot comment]
Non-blocking, and no need to respond to these:

-- Section 3.2.1 --
  The used IPv6 prefix
  may change due to the gateway^1s movement.

Nit: you appear to have a funny apostrophe there.

-- Section 3.2.3 --
  It is required that all
  headers MUST be compressed according to HC base encoding.

Nit: "required" is also a 2119 term, so you don't need both it and MUST.  I suggest one of these:
a. All headers MUST be compressed according to HC base encoding.
b. It is REQUIRED that all headers be compressed according to HC base encoding.

There's a similar sentence in 3.2.4 that could use the same treatment.

IANA has reviewed draft-ietf-6lowpan-btle-08, which is currently in
Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: <6lowpan@lists.ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call:  (Transmission of IPv6 Packets over Bluetooth Low Energy) to Proposed Standard


The IESG has received a request from the IPv6 over Low power WPAN WG
(6lowpan) to consider the following document:
- 'Transmission of IPv6 Packets over Bluetooth Low Energy'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-07-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Bluetooth Low Energy is a low power air interface technology defined
  by the Bluetooth Special Interest Group (BT-SIG).  The standard
  Bluetooth radio has been widely implemented and available in mobile
  phones, notebook computers, audio headsets and many other devices.
  The low power version of Bluetooth is a new specification and enables
  the use of this air interface with devices such as sensors, smart
  meters, appliances, etc.  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.  This document describes
  how IPv6 is transported over Bluetooth Low Energy using 6LoWPAN
  techniques.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6lowpan-btle/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6lowpan-btle/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why
is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Proposed Standard.
This is a normative specification for a protocol (an IP-over-foo
adaptation layer).

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

Bluetooth Low Energy (BT-LE) is a low power air interface technology
defined by the Bluetooth Special Interest Group (BT SIG). While
Bluetooth has been widely implemented, the low power version of
Bluetooth is a new specification and enables the use of this air
interface with devices such as sensors, smart meters, appliances, etc.
The low power variant of Bluetooth is commonly specified in revision
4.0 of the Bluetooth specifications and commonly referred to as
Bluetooth 4.0. This document describes how IPv6 is transported over
Bluetooth Low Energy using 6LoWPAN techniques.

Working Group Summary

Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

This document represents the consensus of the 6LoWPAN WG how to apply
the technology developed for IEEE 802.15.4 to BT-LE.

Document Quality

Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?


The document is a product of the 6LoWPAN working group and has been
reviewed by a small number of working group members. As far as known
to this Shepherd, so far it has been implemented by one company (this
implementation has been demonstrated in the hallway of the IETF 83
meeting). The authors are aware of several other companies that are
interested, including one that has begun implementing. The Bluetooth
4.0 specification and thus BT-LE itself is being implemented widely
(e.g., in the iPhone 4S and iPad 3 and certain modern Macs), so it is
important to agree on an IP-over-foo specification for this link
layer.

Personnel

Who is the Document Shepherd? Who is the Responsible Area
Director?

Carsten Bormann is the Document Shepherd.
Ralph Droms is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The Shepherd has personally reviewed the document, which also led to a
bit of delay and a number of editorial revisions after passing WGLC.
The Shepherd now believes that the document is ready for forwarding to
the IESG for publication as a Proposed Standard.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The document is an output document of the 6LoWPAN WG. However, the
level of detail that was reached by the WG comments during WGLC was
limited. Therefore, the Shepherd did his own detailed review, which
resulted in some editorial improvements after WGLC completion. To
further increase confidence, a separate review was held with the
intarea WG from March 30 to April 13; this was also relayed to the
6man WG on April 4. Ultimately, more input will only come from
implementers -- so far there appears to be only one implementation
information from which has been made public.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No -- the document does not appear to require additional broader
review. As with many IP-over-foo documents, the document bridges
areas of knowledge that are available in the IETF and the Bluetooth
SIG, respectively. The bridging has been mainly done by the authors
(note that the draft has gained a relatively diverse set of authors in
the process.).

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

There are no remaining technical concerns with the document. One
concern might be that there is limited feedback from implementation
and interoperability testing at this point, however that is quite
acceptable for a specification just reaching Proposed Standard level.
It would be normal if it turns out, within a couple of years after
implementation has taken off, that implementation experience motivates
clarifications and a revised specification.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, this has been re-confirmed by each individual author on
2012-05-13/-14.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosures have been made.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is working group consensus behind this document. There is a
limited number of working group participants that are interested in
this specific link-layer technology and qualified for making
contributions and comments.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

The Shepherd is not aware of any discontent related to the specification.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The Shepherd has verified to the best of his ability that there are no
ID nits in this draft.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No such formal review appears to be required.

(13) Have all references within this document been identified as
either normative or informative?

The Document Shepherd believes all references are appropriately split.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No. (This specification is dependent on draft-ietf-6lowpan-nd, which
is at the stage of being processed after IETF last call.)

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

There are no down-references; note that there are normative references
to IEEE 802 and the Bluetooth 4.0 specification.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA considerations for this document, as the relevant
code point needs to be allocated by Bluetooth SIG (see also section
3.1).

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(None.)

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

(None.)

Entered WG last-call on 2011-12-15.
This is a two-week Working-Group Last-Call, partially suspended during
the holidays, so it ends on

  Thursday, 2012-01-05 at 1200 UTC.