Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-btle-14: (with DISCUSS and COMMENT)

["Savolainen Teemu (Nokia-TECH/Tampere)" <[e-mail]>]

Hi Alissa,

>Sorry, I meant private *device* addresses. I was wondering whether the first sentence should say "A 6LN and a 6LBR are RECOMMENDED to use private Bluetooth device addresses" since the recommendation is effectively to use a random device address that changes periodically, which is as far as I can tell the definition of a private Bluetooth device address. In any event, I think the text should be clear about whether 6LNs and 6LBRs should use static or private device addresses or either one.

Ah, now I see. Yes, you are right - static address remains the same at least until the next power cycle, and hence could not change for each connection as mentioned in the next sentence. If no other comments on this, we'll prepare this change for -17.

>Yes, I didn't mean to change the logic of the header compression exception, but just to be more clear about the other case, which is when the device address is known to be <something>. I think the <something> should be a private address only, not any random address. The header-compression-benefits exception could still apply in any case, including where a static device address is used.

I see the point of not mentioning static address there, as it might not change often enough. So text such as below would be better?
--
   In situations where the
   Bluetooth device address is known to be a private device address 
   and/or the header compression
   benefits of embedding the device address in the IID are required to
   support deployment constraints, 6LNs MAY form a 64-bit IID by
   utilizing the 48-bit Bluetooth device address.
--

>Does that make sense?

Yes.

Best regards,

Teemu