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

<johanna.1.nieminen@nokia.com> Mon, 30 January 2012 08:58 UTC

Return-Path: <johanna.1.nieminen@nokia.com>
X-Original-To: 6lowpan@ietfa.amsl.com
Delivered-To: 6lowpan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27D321F858E for <6lowpan@ietfa.amsl.com>; Mon, 30 Jan 2012 00:58:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeVxflQjG075 for <6lowpan@ietfa.amsl.com>; Mon, 30 Jan 2012 00:58:02 -0800 (PST)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id EB69721F8582 for <6lowpan@ietf.org>; Mon, 30 Jan 2012 00:58:01 -0800 (PST)
Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0U8vwIq028050; Mon, 30 Jan 2012 10:57:59 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jan 2012 10:57:58 +0200
Received: from 008-AM1MPN1-062.mgdnok.nokia.com ([169.254.2.111]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Mon, 30 Jan 2012 09:57:57 +0100
From: <johanna.1.nieminen@nokia.com>
To: <cabo@tzi.org>
Thread-Topic: [6lowpan] New version of IPv6 over BT-LE draft
Thread-Index: Aczcwr1lMJzwXEp3RYu7InO0T0ccYwAPXwEAAIryJUA=
Date: Mon, 30 Jan 2012 08:57:56 +0000
Message-ID: <5FA713B99ACAA6478C065A155E206B4617689B2B@008-AM1MPN1-062.mgdnok.nokia.com>
References: <5FA713B99ACAA6478C065A155E206B4617688CC4@008-AM1MPN1-062.mgdnok.nokia.com> <CC5DECAC-4994-4064-B118-5593332B18E2@tzi.org>
In-Reply-To: <CC5DECAC-4994-4064-B118-5593332B18E2@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.21.34.226]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 30 Jan 2012 08:57:58.0193 (UTC) FILETIME=[4343A210:01CCDF2D]
X-Nokia-AV: Clean
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] New version of IPv6 over BT-LE draft
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2012 08:58:02 -0000

Hi,

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

Johanna

>-----Original Message-----
>From: ext Carsten Bormann [mailto:cabo@tzi.org]
>Sent: 27 January, 2012 17:31
>To: Nieminen Johanna.1 (Nokia-NRC/Helsinki)
>Cc: 6lowpan@ietf.org
>Subject: Re: [6lowpan] New version of IPv6 over BT-LE draft
>
>On Jan 27, 2012, at 08:10, <johanna.1.nieminen@nokia.com> 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