Skip to main content

IPv6 over BLUETOOTH(R) Low Energy
draft-ietf-6lo-btle-17

Revision differences

Document history

Date Rev. By Action
2015-10-27
17 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-10-15
17 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-10-14
17 (System) Notify list changed from draft-ietf-6lo-btle@ietf.org, 6lo-chairs@ietf.org, Gabriel.Montenegro@microsoft.com, draft-ietf-6lo-btle.ad@ietf.org, draft-ietf-6lo-btle.shepherd@ietf.org to (None)
2015-09-24
17 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-08-10
17 (System) RFC Editor state changed to EDIT
2015-08-10
17 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-08-10
17 (System) Announcement was received by RFC Editor
2015-08-10
17 (System) IANA Action state changed to No IC from In Progress
2015-08-10
17 (System) IANA Action state changed to In Progress
2015-08-10
17 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2015-08-10
17 Cindy Morgan IESG has approved the document
2015-08-10
17 Cindy Morgan Closed "Approve" ballot
2015-08-10
17 Cindy Morgan Ballot writeup was changed
2015-08-10
17 Cindy Morgan Ballot writeup was changed
2015-08-10
17 Brian Haberman Ballot approval text was generated
2015-08-10
17 Brian Haberman Ballot writeup was changed
2015-08-05
17 Alissa Cooper
[Ballot comment]
Thank you for all of your efforts and candid engagement to get my DISCUSS points resolved. I have cleared the DISCUSS. I did …
[Ballot comment]
Thank you for all of your efforts and candid engagement to get my DISCUSS points resolved. I have cleared the DISCUSS. I did notice one last edit that should probably get made so that Section 5 is consistent with the new text in Section 3.2.2, but will leave it to you to decide whether you want to make the change.

In Section 5:

OLD
For non-link local
  addresses implementations have a choice to support, for example,
  [I-D.ietf-6man-default-iids], [RFC3315], [RFC3972], [RFC4941],
  [RFC5535], or [RFC7217].

NEW
For non-link local
  addresses, implementations are recommended not to embed
  the Bluetooth device address in the IID by default and instead support, for example,
  [RFC3315], [RFC3972], [RFC4941],
  [RFC5535], or [RFC7217].
2015-08-05
17 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2015-08-04
17 Teemu Savolainen New version available: draft-ietf-6lo-btle-17.txt
2015-07-23
16 Teemu Savolainen New version available: draft-ietf-6lo-btle-16.txt
2015-07-20
15 Teemu Savolainen IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-07-20
15 Teemu Savolainen New version available: draft-ietf-6lo-btle-15.txt
2015-07-16
14 Tero Kivinen Request for Telechat review by SECDIR Completed: Ready. Reviewer: Chris Lonvick.
2015-07-13
14 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Niclas Comstedt.
2015-07-10
14 Elwyn Davies Request for Telechat review by GENART Completed: Ready. Reviewer: Elwyn Davies.
2015-07-09
14 Amy Vezza IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2015-07-09
14 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-07-09
14 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-07-08
14 Spencer Dawkins
[Ballot comment]
In this text:

  New addresses are typically generated each time a
  device is powered on.  In random addresses all 48 bits …
[Ballot comment]
In this text:

  New addresses are typically generated each time a
  device is powered on.  In random addresses all 48 bits are
  randomized.  Bluetooth LE does not support device address collision
  avoidance or detection.  However, these 48 bit random device
  addresses have a very small probability of being in conflict within a
  typical deployment.
 
is the working assumption that if a random device address conflict does arise, either a human will recycle power because that's what humans do with electronic devices that don't work, or if no impatient human is available, the device will power off and back on eventually and everything will be fine?

I'm looking at this text:

  In the rare case of Bluetooth LE random device address conflict, a
  6LBR can detect multiple 6LNs with the same Bluetooth LE device
  address, as well as a 6LN with the same Bluetooth LE address as the
  6LBR.  The 6LBR MUST ignore 6LNs with the same device address the
  6LBR has, and the 6LBR MUST have at most one connection for a given
  Bluetooth LE device address at any given moment.  This will avoid
  addressing conflicts within a Bluetooth LE network.
 
and guessing that the Bluetooth LE network doesn't have addressing conflicts, but does that mean that the device that's trying to use a random device address that would cause addressing conflicts if it wasn't being ignored will give up and choose another random device address?
2015-07-08
14 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-07-08
14 Kathleen Moriarty
[Ballot comment]
I also fully support Alissa's discuss points on privacy.

As the draft says, 'when available' for the security and privacy options, so anything …
[Ballot comment]
I also fully support Alissa's discuss points on privacy.

As the draft says, 'when available' for the security and privacy options, so anything that can be done should be to improve this for IPv6 over bluetooth.  Having done some testing of the ability to monitor bluetooth, it can go up to 70' in certain conditions and much less in other conditions.  We were also able to monitor through windows.  This testing was done with an earlier bluetooth version monitoring point to point sessions in various conditions (it was a fun day at work).  People and their IoT devices are much more exposed than they realize especially since the security and privacy options hat can be implemented often are not.  That's just a long way of stating that I support Alissa's discuss.
2015-07-08
14 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2015-07-08
14 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-07-08
14 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2015-07-08
14 Stephen Farrell
[Ballot comment]

- I strongly support Alissa's DISCUSS and would argue that we
ought really try hard to minimise any privacy leakage being
contributed to …
[Ballot comment]

- I strongly support Alissa's DISCUSS and would argue that we
ought really try hard to minimise any privacy leakage being
contributed to by this specification. We basically have one
chance to do this well, after which any leakage becomes yet
another reason to not do the job well in future in other places.
(Based on dodgy but often heard arguments like: "but IPv6/BTLE
already dos this badly, so there's no additional harm in
foo/IPv6/BTLE being just as bad.")

I also note that the fact that some of that leakage relates to
link local addresses doesn't really reduce the damage so much
with a radio based link layer. (Yes, good l2 crypto could help
there, but only if always used everywhere for all packets and I
don't know if BTLE requires that, I suspect it does not.)

- The secdir review in early June made a couple of points that
are worth addressing. [1] I have not seen any response to that
review. (Apologies if I missed it.)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05744.html
2015-07-08
14 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2015-07-07
14 Alissa Cooper
[Ballot discuss]
My understanding from the discussions surrounding draft-ietf-6man-default-iids was that RFC 6282 constitutes an exception to the main recommendation ("By default, nodes SHOULD NOT …
[Ballot discuss]
My understanding from the discussions surrounding draft-ietf-6man-default-iids was that RFC 6282 constitutes an exception to the main recommendation ("By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed the underlying link-layer address in the IID") because the header compression scheme in RFC 6282 requires that the IID be based on the link layer address. I see no text that justifies a similar requirement in this document. I think if this document is going to specify generating the IID from the device address as the only address generation scheme for link-local addresses, it needs to provide a justification for that. Otherwise, the default address generation scheme should be one that generates an opaque IID of limited lifetime. The possibility that the device address is generated randomly and refreshed on each power cycle is important to note, but is not by itself sufficient justification given what I assume is the wider deployment of static device addresses. If the v6 address can provide better privacy protection than the device address, it should.

On that point, there also seems to be a discrepancy between Section 3.2.2 and Section 5. Section 3.2.2 states:

"(After a Bluetooth LE logical link has been established, it
  is referenced with a Connection Handle in HCI.  Thus possibly
  changing device addresses do not impact data flows within existing
  L2CAP channels.  Hence there is no need to change IPv6 link-local
  addresses even if devices change their random device addresses during
  L2CAP channel lifetime)."
 
Section 5 states:

"The IPv6 link-local address configuration described in Section 3.2.2
  strictly binds the privacy level of IPv6 link-local address to the
  privacy level device has selected for the Bluetooth LE.  This means
  that a device using Bluetooth privacy features will retain the same
  level of privacy with generated IPv6 link-local addresses."

If the IID remains the same even when the device address changes, then the IID can be used to correlate activities of the device for the full lifetime of the IID, which goes beyond the lifetime of the device address. So the "privacy level" afforded by the device address is not the same as that of the IID. If this document is going to specify the generation of IIDs based on device addresses, why not regenerate the IID when the device address is regenerated?
2015-07-07
14 Alissa Cooper
[Ballot comment]
Why does this draft reference v4.1 of the Bluetooth spec rather than v4.2?

In 3.2.2, I think RFC 7217 should be added to …
[Ballot comment]
Why does this draft reference v4.1 of the Bluetooth spec rather than v4.2?

In 3.2.2, I think RFC 7217 should be added to the list in this sentence:
"A 6LN can also use a randomly
  generated IID (see Section 3.2.3), for example, as discussed in
  [I-D.ietf-6man-default-iids], or use alternative schemes such as
  Cryptographically Generated Addresses (CGA) [RFC3972], privacy
  extensions [RFC4941], Hash-Based Addresses (HBA, [RFC5535]), or
  DHCPv6 [RFC3315]."

Similarly, in Section 5, s/[I-D.ietf-6man-default-iids]/[RFC7217]/ in this sentence:
"For non-link local
  addresses implementations have a choice to support, for example,
  [I-D.ietf-6man-default-iids], [RFC3972], [RFC4941] or [RFC5535]."
2015-07-07
14 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2015-07-07
14 Joel Jaeggli
[Ballot comment]
from opsdir review by niclas comstedt

Hi,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all …
[Ballot comment]
from opsdir review by niclas comstedt

Hi,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document is for the Standards Track.

This document defines how IPv6 is transported over Low Energi Bluetooth leveraging 6LoWPAN techniques for 802.15.4.

I have no real feedback. The document is well written and makes sense to me. The compression details are a bit outside of my experience so didn’t get into all the details there. There are no real nits (one single referenced draft has a newer version) and my only semantical small change would be:

- 3.2.4 first paragraph, remove “in this document”. Header compression as defined … … is REQUIRED as the basis … … Those two first sentences are a little repetitive which adds to it

- 3.3, should this just be moved up under 3.2.1 or something? Its only referenced there unless I’m missing something and doesn’t need the context of what comes after.
2015-07-07
14 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-07-07
14 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2015-07-07
14 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2015-07-07
14 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2015-07-07
14 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-07-07
14 Barry Leiba
[Ballot comment]
Because of the history of this document, significant explanation was needed -- and provided -- in the shepherd writeup.  Thanks, Gabriel, for the …
[Ballot comment]
Because of the history of this document, significant explanation was needed -- and provided -- in the shepherd writeup.  Thanks, Gabriel, for the good job on that.  The writeup says:

> This support from BT SIG should address the remaining DISCUSS on
> the original document.

It does, indeed (it was my DISCUSS), and this document looks great.  I'm glad things were sorted out with BT SIG, and thanks to everyone for all the work on this.
2015-07-07
14 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2015-07-02
14 Jean Mahoney Request for Telechat review by GENART is assigned to Elwyn Davies
2015-07-02
14 Jean Mahoney Request for Telechat review by GENART is assigned to Elwyn Davies
2015-07-02
14 Tero Kivinen Request for Telechat review by SECDIR is assigned to Chris Lonvick
2015-07-02
14 Tero Kivinen Request for Telechat review by SECDIR is assigned to Chris Lonvick
2015-06-26
14 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2015-06-26
14 Brian Haberman IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2015-06-26
14 Brian Haberman Ballot has been issued
2015-06-26
14 Brian Haberman [Ballot Position Update] New position, Yes, has been recorded for Brian Haberman
2015-06-26
14 Brian Haberman Created "Approve" ballot
2015-06-26
14 Brian Haberman Ballot writeup was changed
2015-06-26
14 Brian Haberman Placed on agenda for telechat - 2015-07-09
2015-06-26
14 Brian Haberman IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup::AD Followup
2015-06-26
14 Brian Haberman Changed consensus to Yes from Unknown
2015-06-25
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-06-25
14 Teemu Savolainen IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-06-25
14 Teemu Savolainen New version available: draft-ietf-6lo-btle-14.txt
2015-06-09
13 Brian Haberman IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2015-06-09
13 (System) IESG state changed to Waiting for Writeup from In Last Call
2015-06-05
13 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Chris Lonvick.
2015-06-01
13 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2015-06-01
13 Amanda Baber
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

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

We understand that this …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

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

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.
2015-05-28
13 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2015-05-28
13 Jean Mahoney Request for Last Call review by GENART is assigned to Elwyn Davies
2015-05-28
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2015-05-28
13 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2015-05-28
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Chris Lonvick
2015-05-28
13 Tero Kivinen Request for Last Call review by SECDIR is assigned to Chris Lonvick
2015-05-26
13 Amy Vezza IANA Review state changed to IANA - Review Needed
2015-05-26
13 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: <6lo@ietf.org>
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IPv6 over …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: <6lo@ietf.org>
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IPv6 over BLUETOOTH(R) Low Energy) to Proposed Standard


The IESG has received a request from the IPv6 over Networks of
Resource-constrained Nodes WG (6lo) to consider the following document:
- 'IPv6 over BLUETOOTH(R) 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 2015-06-09. 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 Smart is the brand name for the Bluetooth low energy
  feature in the Bluetooth specification defined by the Bluetooth
  Special Interest Group.  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 specification that enables the use of this air interface with
  devices such as sensors, smart meters, appliances, etc.  The low
  power variant of Bluetooth is standardized since the revision 4.0 of
  the Bluetooth specifications, although version 4.1 or newer is
  required for IPv6.  This document describes how IPv6 is transported
  over Bluetooth low energy using 6LoWPAN techniques.




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

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


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


2015-05-26
13 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2015-05-26
13 Brian Haberman Last call was requested
2015-05-26
13 Brian Haberman Last call announcement was generated
2015-05-26
13 Brian Haberman Ballot approval text was generated
2015-05-26
13 Brian Haberman Ballot writeup was generated
2015-05-26
13 Brian Haberman IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2015-05-25
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-05-25
13 Teemu Savolainen New version available: draft-ietf-6lo-btle-13.txt
2015-05-21
12 Brian Haberman Note added 'The IPSP specification is available at https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=296307'
2015-05-20
12 Brian Haberman IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2015-05-20
12 Brian Haberman Notification list changed to draft-ietf-6lo-btle@ietf.org, 6lo-chairs@ietf.org, Gabriel.Montenegro@microsoft.com, draft-ietf-6lo-btle.ad@ietf.org, draft-ietf-6lo-btle.shepherd@ietf.org from "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>
2015-05-18
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-05-18
12 Teemu Savolainen New version available: draft-ietf-6lo-btle-12.txt
2015-05-13
11 Brian Haberman IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2015-04-28
11 Brian Haberman IESG state changed to AD Evaluation from AD Evaluation::External Party
2015-04-27
11 Teemu Savolainen New version available: draft-ietf-6lo-btle-11.txt
2015-04-08
10 Brian Haberman Under review by the INT directorate
2015-04-08
10 Brian Haberman IESG state changed to AD Evaluation::External Party from AD Evaluation
2015-03-02
10 Brian Haberman IESG state changed to AD Evaluation from Publication Requested
2015-02-27
10 Gabriel Montenegro
(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? …
(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. The BT SIG has issued subsequent updates (to date,
Bluetooth 4.1 and 4.2). This document describes how IPv6 is transported over
Bluetooth Low Energy 4.1 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 6Lo WG on how to apply
the technology developed originally for IEEE 802.15.4 applied to BT-LE.
This document initially appeared in the 6LoWPAN WG, the predecessor to the
6Lo WG, and made it all the way to approval at the IESG (last ballot comment: 2013-03-07).
There is still one outstanding DISCUSS the clearing of which required some work by the
Bluetooth SIG. That initial version of the draft used a fixed L2CAP channel ID. In this 2 year hiatus,
the BT SIG had a policy change, so instead of assigning the fixed channel ID, they defined the
Internet Protocol Support Profile (IPSP) 1.0. IPSP uses Connection-oriented Channels and
negotiation of dynamic channel ID. This enabled a simplification in the draft as
shown by the diff between versions 00 and 01:
http://tools.ietf.org/wg/6lo/draft-ietf-6lo-btle/draft-ietf-6lo-btle-01-from-00.diff.html
This support from BT SIG should address the remaining DISCUSS on the original document.
This document depends on IPSP 1.0, which requires Bluetooth 4.1 or newer.
Since these changes were significant, the document went back to the working group, including
the corresponding last call. There were few comments this time around (including Dave Thaler, Carsten
Bormann and this shepherd). The document is improved as compared to the first time it went to IESG.

One point worth noting is that there was a thread discussing whether we'd use 64-bit IID's for this
draft. This is a more general point that would apply to more than just this draft, so it quickly became
more a discussion of https://tools.ietf.org/html/rfc7421 than a discussion of this particular draft.
In keeping with rfc7421's advice and per preference expressed by several WG members as well as guidance
by Ole Troan (6man co-chair), we stuck to 64-bit IID's. It may be a worthwhile goal to go revise that part of the
IPv6 addressing architecture, but "that's not a problem that should be solved in an IP over foo document" (Ole Troan).

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 6Lo (and 6LoWPAN) working group and has been
reviewed by a small number of working group members. It has also been reviewed within the
Bluetooth SIG (including its Internet Working Group). As far as it is known
to this Shepherd, so far it has been implemented by several companies (one
implementation has been demonstrated in the hallway of the IETF 83
meeting). The authors are aware of several other companies that have
implemented (including Nordic: http://www.nordicsemi.com/eng/News/News-releases/Product-Related-News/Nordic-Semiconductor-IPv6-over-Bluetooth-Smart-protocol-stack-for-nRF51-Series-SoCs-enables-small-low-cost-ultra-low-power-Internet-of-Things-applications and also in Bluez). The Bluetooth
4.1 specification and thus BT-LE itself is implemented widely
(e.g., in the many current phones, tablets and laptops), 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?

Gabriel Montenegro is the Document Shepherd.
Brian Haberman 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 caused an extra
revision 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 of the 6Lo WG and previously, the 6LoWPAN WG.
In its long history the document has benefitted from review both within the
WG as well as the IESG (full review cycle the first time around) in addition to
other areas (6man and Intarea held reviews of the first document).
There are several known implementations, which speaks for its clarity to
implementors. One can always find nits, but I think the document is useful and ready
to be published.

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

(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. Again in Feb. 2015.

(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.
On the contrary there is industry support and interest.

(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. The only warning output by IDnits does not apply,
as IPSP (published by the BT SIG) is a valid reference for a proposed standard.

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

(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, Bluetooth 4.1 and IPSP specifications.

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

(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.)
2015-02-27
10 Gabriel Montenegro Responsible AD changed to Brian Haberman
2015-02-27
10 Gabriel Montenegro IETF WG state changed to Submitted to IESG for Publication from WG Document
2015-02-27
10 Gabriel Montenegro IESG state changed to Publication Requested
2015-02-27
10 Gabriel Montenegro IESG process started in state Publication Requested
2015-02-27
10 Gabriel Montenegro Intended Status changed to Proposed Standard from None
2015-02-27
10 Gabriel Montenegro Changed document writeup
2015-02-23
10 Teemu Savolainen New version available: draft-ietf-6lo-btle-10.txt
2015-02-19
09 Gabriel Montenegro Notification list changed to "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>
2015-02-19
09 Gabriel Montenegro Document shepherd changed to Gabriel Montenegro
2015-02-19
09 Teemu Savolainen New version available: draft-ietf-6lo-btle-09.txt
2015-02-13
08 Teemu Savolainen New version available: draft-ietf-6lo-btle-08.txt
2015-01-16
07 Teemu Savolainen New version available: draft-ietf-6lo-btle-07.txt
2015-01-09
06 Teemu Savolainen New version available: draft-ietf-6lo-btle-06.txt
2015-01-09
05 Teemu Savolainen New version available: draft-ietf-6lo-btle-05.txt
2014-12-16
04 Teemu Savolainen New version available: draft-ietf-6lo-btle-04.txt
2014-09-01
03 Teemu Savolainen New version available: draft-ietf-6lo-btle-03.txt
2014-07-24
02 Samita Chakrabarti Document shepherd changed to Dr. Carsten Bormann
2014-07-24
02 Samita Chakrabarti Document shepherd changed to (None)
2014-06-11
02 Teemu Savolainen New version available: draft-ietf-6lo-btle-02.txt
2014-05-01
01 Teemu Savolainen New version available: draft-ietf-6lo-btle-01.txt
2013-11-07
00 Ulrich Herberg draft-ietf-6lowpan-btle is moved from 6lowpan to the 6lo WG.
2013-11-07
00 Ulrich Herberg Set of documents this document replaces changed to draft-ietf-6lowpan-btle from None
2013-11-07
00 Teemu Savolainen New version available: draft-ietf-6lo-btle-00.txt