[6lo] Spencer Dawkins' No Objection on draft-ietf-6lo-btle-14: (with COMMENT)

["Spencer Dawkins" <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-6lo-btle-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6lo-btle/



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