Subject: [6lo] Comments on draft-ietf-6lo-btle-00

From: Dave Thaler <[email-masked]>
Date: Wed, 26 Mar 2014 00:15:31 +0000

Here's my comments on this draft...

I find the lack of consistency between Figures 1 and 3 to be confusing.
For example, figure 1 has "Logical Link Control and Adaptation" but figure 3 has
"BT-LE L2CAP".  I assume these are the same thing but are using gratuitously
different labels.   Another example is that figure 1 shows "Host Controller
Interface" but figure 3 does not, and I cannot tell why.  I would expect the
bottom half of both figures to look identical, or there to be an explanation
in the text of why they look different.

Section 3.2.1:
> Alternatively, a randomly generated IID (see Section 3.2.2), MAY be used instead.

draft-ietf-6man-default-iids would make that MAY be a SHOULD, and it would be
good to not have contradicting documents between WGs. It would be good to find
wording that defers to 6MAN on the appropriate level. An example of such
wording might be:

"Alternatively, a randomly generated IID (see Section 3.2.2), can be used instead
as discussed in [I-D.ietf-6man-default-iids]."

Section 3.2.2:
> A BT-LE 6LN MUST register its address with the 6LBR by sending a
> Neighbor Solicitation (NS) message with the ARO option and process
> the Neighbor Advertisement (NA) accordingly.

Does that mean RFC 4429 (Optimistic DAD) is legal or illegal?

> NS with the ARO
> option SHOULD be sent irrespective of whether the IID is derived from
> the unique 48 bit BT-LE device address or the IID is a random value
> that is generated as per the privacy extensions for stateless address
> autoconfiguration [RFC4941].

Those aren't the only two possibilities.  What about CGAs (RFC3972)?
What about draft-gont-6man-stable-privacy-addresses?  What if you
need to use DHCPv6?   Reword to not attempt to enumerate possibilities,
such as simply "... irrespective of the method used to generate the IID."

> Although RFC 4941 [RFC4941] permits the
> use of deprecated addresses for old connections, in this
> specification we mandate that one interface MUST NOT use more than
> one IID at any one time.

Why?  This seems to be the biggest issue in the spec.  That would
seem to preclude the use of both temporary addresses and CGAs, and
hence introduce security/privacy issues that are missing from the
Security Considerations section.  The privacy problems are covered
in draft-ietf-6man-ipv6-address-generation-privacy.

Section 3.2.4:
> As described in the
> Section 3.2 the master will not forward link-local multicast messages
> to other slaves connected to the master.

This is unclear. Is the link presented to IP as a multicast-capable interface
or not?  If not, then "link-local" doesn't belong in the quote and of course a bunch of protocols just won't work
(just like they don't work on any other NBMA link).

It seems odd to say that it will forward multicast messages of
scopes greater than link local, but not forward link-local ones.

-Dave

---

From: <[email-masked]>
Date: Thu, 27 Mar 2014 12:52:45 +0000

Hi Dave and thank you very much for your review.

Please see responses inline.

>"BT-LE L2CAP".  I assume these are the same thing but are using gratuitously

Same thing. L2CAP is opened in Section 2.1 text. The Figure 1 has no acronyms while file Figure 3 has ~nothing but acronyms:)

We could add acronyms to Figure 1 if it would help?

>Interface" but figure 3 does not, and I cannot tell why.  I would expect the

The HCI is device internal interface significant for Bluetooth stack architecture and commonly shown in architecture diagrams.

>in the text of why they look different.

Maybe this would be fixed by renaming Figuer 1 to BT-LE Stack Architecture and adding explanation to the text. Will look into it.

>as discussed in [I-D.ietf-6man-default-iids]."

Is a SHOULD too strong if thinking e.g. home and industry automation cases? Or are those cases exactly those where this SHOULD could be ignored?

Could that reference be informative, if added?

>Does that mean RFC 4429 (Optimistic DAD) is legal or illegal?

RFC 6775 says:" An example of this is Optimistic DAD [RFC4429].  Such extensions do not apply when this specification is being used, since it uses ARO for DAD (which is neither optimistic nor pessimistic -- always one round trip to the router to check DAD)."

I read it so that Optimistic DAD is illegal, as host needs to receive reply to ARO with "Success" before using the address.

Is the text in RFC 6775 enough, then?

>such as simply "... irrespective of the method used to generate the IID."

Right, that makes sense. Will update as proposed.

>in draft-ietf-6man-ipv6-address-generation-privacy.

I had some trouble recollecting the reasons for this. I think the text is what it is because of header compression. If there are multitude of IIDs in use at the same time, the IID must be transported with each packet and hence compression is less efficient. With one-IID-at-a-time the IID can be inferred with help of ND cache and does not need to be transported with every packet.

That might actually be a problem, for the future in addition to temporary/CGA addresses. I think we should actually modify this text, to allow transport of IID with every packet. 

Perhaps the text could say that the IID can be transported with the packet (SAM=01), but it can be also elided. If it is elided, then the IID is inferred (with help of ND cache).

>scopes greater than link local, but not forward link-local ones.

The text indeed seems to be confusing. I think the master should not forward multicast of greater scopes either...

The IP link-local multicasting is actually a topic I could discuss further with my coauthors and also take to BT SIG discussions - to gauge views in there (e.g. on service discovery on top of IP...).

Best regards,

	Teemu

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 27 Mar 2014 14:05:07 +0100

On 27 Mar 2014, at 13:52, <[email-masked]> <[email-masked]> wrote:

> Will update

We'll need to discuss how to handle updates to this document.
(It’s good to have the issues raised by Dave handled, but it is also easy to introduce new errors and we should arrange for appropriate WG review.)

Grüße, Carsten

---

From: <[email-masked]>
Date: Fri, 28 Mar 2014 08:06:38 +0000

Yes.

There will be an update anyway needed due to BT SIG's outcome (that we are still waiting for). Once we have all input available, we'll see what must (and could) be changed in the I-D, and at that point I believe we shall discuss what is the best procedural way forward. It may very well include WG review (such as WGLC). Let's see. 

Best regards,

	Teemu

-----Original Message-----
From: ext Carsten Bormann [mailto:[email-masked]] 
Sent: 27. maaliskuuta 2014 15.05
To: Savolainen Teemu (Nokia-CTO/Tampere)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [6lo] Comments on draft-ietf-6lo-btle-00

We'll need to discuss how to handle updates to this document.
(It's good to have the issues raised by Dave handled, but it is also easy to introduce new errors and we should arrange for appropriate WG review.)

Grüße, Carsten

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 28 Mar 2014 09:35:17 +0100

On Thursday, March 27, 2014, Carsten Bormann wrote:

> On 27 Mar 2014,
> (It's good to have the issues raised by Dave handled, but it is also easy
> to introduce new errors and we should arrange for appropriate WG review.)

I support updating all 6lo documents not only this. Many just want to
submit to WGLC. The WG reviews are only encouraged when there are WG
authors answering questions for WG docs, and I am still waiting your
answers of my questions on general compression draft.

AB