Re: [6lowpan] New version of IPv6 over BT-LE draft

[<[e-mail]>]

Hi,

We will prepare a new version by next week. See my initial comments below:

Johanna

>-----Original Message-----
>From: ext Carsten Bormann [mailto:[e-mail]]
>Sent: 27 January, 2012 17:31
>To: Nieminen Johanna.1 (Nokia-NRC/Helsinki)
>Cc: [e-mail]
>Subject: Re: [6lowpan] New version of IPv6 over BT-LE draft
>
>On Jan 27, 2012, at 08:10, <[e-mail]> wrote:
>
>> Hi,
>>
>> Just to inform that our draft "Transmission of IPv6 Packets over Bluetooth
>Low Energy" was updated some weeks ago based on the WGLC comments.
>Version 5 is available at:
>> https://datatracker.ietf.org/doc/draft-ietf-6lowpan-btle/.
>
>Thanks, Johanna.
>
><with chair hat>
>
>This draft passed WGLC on 2012-01-05.
>While trying to write the proto writeup as a prerequisite for asking for
>publication as a Standards-Track, I found a number of (in part not entirely
>trivial) editorial issues that I'm sending directly to the authors.
>
>I also have a couple of technical observations that I believe need to be
>addressed before we can go ahead.
>
>1)
>            A
>            device MAY also derive the IID of the other endpoint of a L2CAP
>            connection from the Link Layer connection establishment messages.
>
>-So how do we get consistency here?
>-It is not acceptable if endpoints derive the wrong address -- among -many
>problems, pseudoheader-based checksums will simply fail.
>

We could say the the device MUST derive the IID of the other endpoint but not mandate which of the two methods will be used. The IID should be correct using either method (ND message exchange or Link Layer connection establishment messages).

>2)
>            When a BT-LE slave transmits an IPv6 packet to a remote destination
>            using global IPv6 addresses, the slave MUST elide the IPv6 source
>            address.
>
>-To be able to compress a global prefix, it must have acquired a -context.  How
>do you make sure that is the case, to enable fulfilling -that MUST?

We can add: If a context is defined for the prefix of the IPv6 source address,
the slave MUST elide the IPv6 source address.

>
>3)
>            The 6LBR/master can infer the elided IPv6 source address
>            since 1) the master/6LBR has previously assigned the prefix to the
>            slaves;
>
>-In IPv6, there may be more than one prefix.
>-That's why RFC 6282 has a context identifier.

Again, context must be explicitly stated here.

>
>4)
>
>            If a context is defined for the prefix of the IPv6 source address,
>            the master/6LBR MUST elide that prefix as well.
>
>-In summary, we use RFC 6282, but extend it to make, in some of the -cases,
>compression mandatory?

Yes. BT-LE operates in a STAR topology, making compression possible in several cases. We have chosen to mandate compression whenever it is possible.

>-The intro to this section should say that.
>
>
>Summarizing my observations:
>a) Whenever the spec leaves a choice, it must either
>-- explain why this choice does not cause interoperability problems, or
>-- make sure that peers make the same choice.
>b) Whenever the spec constrains an existing spec, it must
>-- explain why the constrained behavior is always indeed possible at all,
>-- make sure that both peers operate the constraint in the same way.
>
>I don't see a way around generating a -06 that addresses these issues, before
>I can do the proto writeup -- if we don't fix these items now, they will be
>much more work to fix in the IESG phase.
>
>Grüße, Carsten