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 Bluetoo=
th
>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 entirel=
y
>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 L2CA=
P
>            connection from the Link Layer connection establishment messag=
es.
>
>-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 n=
ot mandate which of the two methods will be used. The IID should be correct=
 using either method (ND message exchange or Link Layer connection establis=
hment messages).

>2)
>            When a BT-LE slave transmits an IPv6 packet to a remote destin=
ation
>            using global IPv6 addresses, the slave MUST elide the IPv6 sou=
rce
>            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 addre=
ss,
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 addr=
ess,
>            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 seve=
ral 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, bef=
ore
>I can do the proto writeup -- if we don't fix these items now, they will b=
e
>much more work to fix in the IESG phase.
>
>Gr=FC=DFe, Carsten