From my.mailing.acc@gmail.com  Mon Jan 16 08:27:51 2012
Return-Path: <my.mailing.acc@gmail.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 C4C4921F85E5 for <6lowpan@ietfa.amsl.com>; Mon, 16 Jan 2012 08:27:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.638
X-Spam-Level: 
X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 ugzVuQDyUE2k for <6lowpan@ietfa.amsl.com>; Mon, 16 Jan 2012 08:27:51 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59CB421F8582 for <6lowpan@ietf.org>; Mon, 16 Jan 2012 08:27:51 -0800 (PST)
Received: by obbwc12 with SMTP id wc12so1412523obb.31 for <6lowpan@ietf.org>; Mon, 16 Jan 2012 08:27:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6GvLm33SJLHiibw9WbVTctAuCPzzG+Z+xheadfeJLus=; b=G45Pk7/Pw5N77j4am06lmqNCm5hQzRQac+iSy8Kj097S2oURbiSV08NjVncPTXXrRt Rft6fA7tiQzM4e9lYrL5PpY5pVC8LfQc1/7gixBjYchR+9Ox5/Jgth2wvDACxMw0LnM9 RR2HY/thNHxppCDw7VP8HjovXPceZGVDirCG0=
MIME-Version: 1.0
Received: by 10.182.122.71 with SMTP id lq7mr11580273obb.33.1326731271027; Mon, 16 Jan 2012 08:27:51 -0800 (PST)
Received: by 10.182.199.1 with HTTP; Mon, 16 Jan 2012 08:27:51 -0800 (PST)
In-Reply-To: <CAHoqu_oacOGQR+1MbNZJzLQjuDrQ6ZOcs=i6PiNOoF=nwsVhpA@mail.gmail.com>
References: <CAHoqu_oacOGQR+1MbNZJzLQjuDrQ6ZOcs=i6PiNOoF=nwsVhpA@mail.gmail.com>
Date: Mon, 16 Jan 2012 21:57:51 +0530
Message-ID: <CAHoqu_pkJ9onU8k2r-3gWEbQmXJTs05zoGtzKqAazZGRxGy5OQ@mail.gmail.com>
From: Tom <my.mailing.acc@gmail.com>
To: 6lowpan@ietf.org
Content-Type: multipart/alternative; boundary=f46d044787011f3ad204b6a7b270
Subject: [6lowpan] ND-17
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, 16 Jan 2012 16:27:51 -0000

--f46d044787011f3ad204b6a7b270
Content-Type: text/plain; charset=ISO-8859-1

Hi All,

Kindly clarify:

1) Section 5.3 demands "In all cases the RS retransmissions are terminated
when a RA is received."
Is this also applicable when a RA is received with router lifetime is set
to zero (e.g a router going down as suggested in rfc4861).

2) TBD4 number (155 XXX) conflicts with the one allocated for RPL.
Is there a other suggested value or one under common agreement outside
ND-17 used for interoperability.

3) Believe there is a typo here? (page 49, section 12)
o TBD3 = 33
o TBD4 = 155 XXX
o TBD3 = 156 XXX -> Believe this is a typo.

Regards,
Tom

--f46d044787011f3ad204b6a7b270
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi All,=A0<br><br>Kindly clarify: <br><br>1) Section 5.3 demands &quot;In a=
ll cases the RS retransmissions are terminated when a RA is received.&quot;=
<br>Is this also applicable when a RA is received with router lifetime is s=
et to zero (e.g a router going down as suggested in rfc4861).<br>
<br>2) TBD4 number (155 XXX) conflicts with the one allocated for RPL. <br>=
Is there a other suggested value or one under common agreement outside ND-1=
7 used for interoperability.  <br><br>3) Believe there is a typo here? (pag=
e 49, section 12)<br>
o TBD3 =3D 33<br>o TBD4 =3D 155 XXX<br>o TBD3 =3D 156 XXX -&gt; Believe thi=
s is a typo. <br><br>Regards, <br>Tom

--f46d044787011f3ad204b6a7b270--

From cabo@tzi.org  Mon Jan 16 09:40:47 2012
Return-Path: <cabo@tzi.org>
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 1500421F8628 for <6lowpan@ietfa.amsl.com>; Mon, 16 Jan 2012 09:40:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.525
X-Spam-Level: 
X-Spam-Status: No, score=-105.525 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 3GMOvLkUEAOU for <6lowpan@ietfa.amsl.com>; Mon, 16 Jan 2012 09:40:46 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDAC21F8627 for <6lowpan@ietf.org>; Mon, 16 Jan 2012 09:40:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q0GHeS25027279; Mon, 16 Jan 2012 18:40:28 +0100 (CET)
Received: from [192.168.217.117] (p5B3E6537.dip.t-dialin.net [91.62.101.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 86B51176; Mon, 16 Jan 2012 18:40:28 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAHoqu_pkJ9onU8k2r-3gWEbQmXJTs05zoGtzKqAazZGRxGy5OQ@mail.gmail.com>
Date: Mon, 16 Jan 2012 18:40:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <054A47D4-276D-44FB-96AD-08BD38BE6521@tzi.org>
References: <CAHoqu_oacOGQR+1MbNZJzLQjuDrQ6ZOcs=i6PiNOoF=nwsVhpA@mail.gmail.com> <CAHoqu_pkJ9onU8k2r-3gWEbQmXJTs05zoGtzKqAazZGRxGy5OQ@mail.gmail.com>
To: Tom <my.mailing.acc@gmail.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] ND-17
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, 16 Jan 2012 17:40:47 -0000

Hi Tom,

(WG chair hat off, individual WG member hat on:)

> 1) Section 5.3 demands "In all cases the RS retransmissions are =
terminated when a RA is received."
> Is this also applicable when a RA is received with router lifetime is =
set to zero (e.g a router going down as suggested in rfc4861).

Well, you could consider it to be, but because of the lifetime it then =
restarts right after 0 seconds=85
Yes, something like this could be spelled out.

> 2) TBD4 number (155 XXX) conflicts with the one allocated for RPL.=20
> Is there a other suggested value or one under common agreement outside =
ND-17 used for interoperability.=20

The same is true for TBD1 (31) and TBD2 (32), which have been assigned =
in the meantime:
31      DNS Search List Option                  [RFC6106]
32      Proxy Signature (PS)                    =
[RFC-ietf-csi-proxy-send-05.txt]

These should be relatively painless, but 155 might hurt in interop =
testing.
Good question, I'll defer to the interop testing community.

> 3) Believe there is a typo here? (page 49, section 12)
> o TBD3 =3D 33
> o TBD4 =3D 155 XXX
> o TBD3 =3D 156 XXX -> Believe this is a typo.=20

Yes, this is a typo; this should be TBD5.

The numbering of course will be solved once we have actual IANA =
assignments.
Depending on when the spec approval happens, 33 and 156 may also go to =
other protocols in the meantime.

I believe we could go for an RFC4020 style early allocation if this =
uncertainty creates hardships.

Two other observations:
-- we are at ND-18 already.  Please always use the most recent I-D, =
available at:

    http://tools.ietf.org/html/draft-ietf-6lowpan-nd

(and now finally with WG chair hat:)

-- please indicate your name on your mailing list messages (I'm assuming =
that Tom is not your only name, which of course could be the case in =
several locales).

Gr=FC=DFe, Carsten


From cabo@tzi.org  Thu Jan 19 06:36:08 2012
Return-Path: <cabo@tzi.org>
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 E858C21F8624; Thu, 19 Jan 2012 06:36:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 MIcfjaT3WZD3; Thu, 19 Jan 2012 06:36:08 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C698221F861F; Thu, 19 Jan 2012 06:36:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q0JEZvR8020602; Thu, 19 Jan 2012 15:35:57 +0100 (CET)
Received: from [192.168.217.117] (p5489B242.dip.t-dialin.net [84.137.178.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1DFA1161; Thu, 19 Jan 2012 15:35:57 +0100 (CET)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: Carsten Bormann <cabo@tzi.org>
Date: Thu, 19 Jan 2012 15:35:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <666B33A3-CD9C-47C9-8DB5-25A3234572A0@tzi.org>
References: <9E2944CA-16CF-4985-9DA6-B7A1A03EFF10@gmx.net>
To: 6lowpan <6lowpan@ietf.org>, core WG <core@ietf.org>, lwip@ietf.org
X-Mailer: Apple Mail (2.1251.1)
Subject: [6lowpan] Fwd: Smart Object Security Workshop Announcement
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: Thu, 19 Jan 2012 14:36:09 -0000

This workshop should be of interest to the whole constrained =
node/network cluster of working groups*)
If you plan to come to Paris, plan to go to:

-- Fri 2012-03-23: Smart Object Security Workshop
-- Sat/Sun -24/-25: ETSI CoRE plugtest
-- Mon-Fri -26..-30: IETF83

If you don't have an implementation with you, you get a nice free =
weekend in Paris :-)

Please see below for the link to the announcement.

Gr=FC=DFe, Carsten

*) If you wonder why ROLL is not in the To:-list: The ROLL mailing list =
already got it's own copy due to an attentive AD in the right time zone =
:-)

Begin forwarded message:

> From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
> Subject: Smart Object Security Workshop Announcement
> Date: January 19, 2012 11:21:57 +0100
> To: IETF-Discussion list <ietf@ietf.org>
>=20
> Hi all,
>=20
> we would like to make you aware of a workshop on Smart Object Security =
on the 23rd March 2012 in Paris (attached to the IETF meeting).
>=20
> We are seeking input from participants to share their thoughts about =
the ability to utilize existing and widely deployed security mechanisms =
for smart objects.
>=20
> In particular, we are interested to hear about:
> 	=95 What techniques for issuing credentials have been deployed?
> 	=95 What extensions are useful to make existing security =
protocols more suitable for smart objects?
> 	=95 What type of credentials are frequently used?
> 	=95 What experience has been gained when implementing and =
deploying application layer, transport layer, network layer, and link =
layer security mechanisms (or a mixture of all of them)?
> 	=95 How can =93clever=94 implementations make security protocols =
a better fit for constrained devices?
> 	=95 Are there lessons we can learn from existing deployments?
>=20
> More workshop details can be found on the webpage of our host:
> http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/
>=20
> If you plan to participate at the workshop please drop us a message =
(with a short description of what you are planning to contribute) and we =
can give you an early notice regarding your participation.=20
>=20
> Greetings
> The Workshop Organizers
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


From ulrich@herberg.name  Thu Jan 19 15:32:36 2012
Return-Path: <ulrich@herberg.name>
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 3EF2E21F85DF for <6lowpan@ietfa.amsl.com>; Thu, 19 Jan 2012 15:32:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001]
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 8xCHWTJ2iiF7 for <6lowpan@ietfa.amsl.com>; Thu, 19 Jan 2012 15:32:35 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5339921F85D0 for <6lowpan@ietf.org>; Thu, 19 Jan 2012 15:32:35 -0800 (PST)
Received: by werp11 with SMTP id p11so474907wer.31 for <6lowpan@ietf.org>; Thu, 19 Jan 2012 15:32:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ibxKHlzxY+WTDyTq4wuwUJrWNzz1JsVnpTdRbPevTtg=; b=Ax+cdvO0y5f3qWYRFvIdhadx87++sh3bYdeY4UTIZYx8PaxmZ9I/G4/xQsaOaKNCyz huD0ebGrD/EjkEHWbMrpSlsFFdXVqY0dCOi4+Cf8AZk/P6wWFzOGwM3v5OutLM+fysqK I9kSLd/Dxvz+bjCaRZhTs/+59bS5w9PYr9nIY=
MIME-Version: 1.0
Received: by 10.180.109.77 with SMTP id hq13mr42388132wib.7.1327015953112; Thu, 19 Jan 2012 15:32:33 -0800 (PST)
Received: by 10.216.54.146 with HTTP; Thu, 19 Jan 2012 15:32:32 -0800 (PST)
In-Reply-To: <49940D6A-23D5-4EF9-A328-E4C5F81F3A36@tzi.org>
References: <72211CB7-0790-4F0B-A47D-40BFD83EEA81@tzi.org> <49940D6A-23D5-4EF9-A328-E4C5F81F3A36@tzi.org>
Date: Thu, 19 Jan 2012 15:32:32 -0800
Message-ID: <CAK=bVC9EXzubwsTYPUG9n3xZB5JN_A9JG8Oo4Y8msYp7mB8whQ@mail.gmail.com>
From: Ulrich Herberg <ulrich@herberg.name>
To: 6lowpan <6lowpan@ietf.org>
Content-Type: multipart/alternative; boundary=e89a8f3ba4457f1da704b6e9fa8b
Subject: Re: [6lowpan] [Roll] Cross-layer issues in Constrained Node/Networks: informal get-together
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: Thu, 19 Jan 2012 23:32:36 -0000

--e89a8f3ba4457f1da704b6e9fa8b
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,

it has been a while since the last IETF, and I was wondering whether was
any activity following the informal "cross-layer issues" meeting during the
last IETF. I tried to recover the notes taken back then, but the link to
http://grenache.tools.ietf.org:9001/p/notes-ietf-82-cross-layer
seems to be dead. Did anyone keep the notes somewhere else?

Regards
Ulrich

On Wed, Nov 16, 2011 at 6:56 PM, Carsten Bormann <cabo@tzi.org> wrote:

> On Nov 15, 2011, at 13:42, Carsten Bormann wrote:
>
> > We are going to have an informal get-together to discuss some of these
> > issues at
> >
> >       Thu, 1740-1940, room 102
>
> I have started collecting slides for this event.
> We don't need slides to discuss something, but where they help, I would
> like to have them before the meeting.
>
> Observe*) the current set of slides at
>
>        http://www.tzi.org/~cabo/cross-layer.pdf
>
> Gr=FC=DFe, Carsten
>
> *) Sorry, no CoAP server there yet=85  Manual repeated HTTP GET required.
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>

--e89a8f3ba4457f1da704b6e9fa8b
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>it has been a while since the last IETF, and I was wondering whe=
ther was any activity following the informal &quot;cross-layer issues&quot;=
 meeting during the last IETF. I tried to recover the notes taken back then=
, but the link to <a href=3D"http://grenache.tools.ietf.org:9001/p/notes-ie=
tf-82-cross-layer">http://grenache.tools.ietf.org:9001/p/notes-ietf-82-cros=
s-layer</a> <br>
seems to be dead. Did anyone keep the notes somewhere else?<br><br>Regards<=
br>Ulrich<br><br><div class=3D"gmail_quote">On Wed, Nov 16, 2011 at 6:56 PM=
, Carsten Bormann <span dir=3D"ltr">&lt;<a href=3D"mailto:cabo@tzi.org">cab=
o@tzi.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Nov 15, 2011, at 13:42,=
 Carsten Bormann wrote:<br>
<br>
&gt; We are going to have an informal get-together to discuss some of these=
<br>
&gt; issues at<br>
&gt;<br>
&gt; =A0 =A0 =A0 Thu, 1740-1940, room 102<br>
<br>
</div>I have started collecting slides for this event.<br>
We don&#39;t need slides to discuss something, but where they help, I would=
 like to have them before the meeting.<br>
<br>
Observe*) the current set of slides at<br>
<br>
 =A0 =A0 =A0 =A0<a href=3D"http://www.tzi.org/%7Ecabo/cross-layer.pdf" targ=
et=3D"_blank">http://www.tzi.org/~cabo/cross-layer.pdf</a><br>
<br>
Gr=FC=DFe, Carsten<br>
<br>
*) Sorry, no CoAP server there yet=85 =A0Manual repeated HTTP GET required.=
<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
Roll mailing list<br>
<a href=3D"mailto:Roll@ietf.org">Roll@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/roll" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/roll</a><br>
</div></div></blockquote></div><br>

--e89a8f3ba4457f1da704b6e9fa8b--

From esko.dijk@philips.com  Thu Jan 26 07:34:41 2012
Return-Path: <esko.dijk@philips.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 8306121F8669 for <6lowpan@ietfa.amsl.com>; Thu, 26 Jan 2012 07:34:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.008
X-Spam-Level: 
X-Spam-Status: No, score=-4.008 tagged_above=-999 required=5 tests=[AWL=-0.409, 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 J8nu07izkHvz for <6lowpan@ietfa.amsl.com>; Thu, 26 Jan 2012 07:34:40 -0800 (PST)
Received: from AM1EHSOBE006.bigfish.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2B921F8674 for <6lowpan@ietf.org>; Thu, 26 Jan 2012 07:34:40 -0800 (PST)
Received: from mail60-am1-R.bigfish.com (10.3.201.246) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 26 Jan 2012 15:34:39 +0000
Received: from mail60-am1 (localhost [127.0.0.1])	by mail60-am1-R.bigfish.com (Postfix) with ESMTP id 5FFE5403C6; Thu, 26 Jan 2012 15:34:39 +0000 (UTC)
X-SpamScore: -38
X-BigFish: VPS-38(zz217bL15d6O9251Jc89bh15bfK542M853kzz1202hzz1033IL8275dhz2dhc1bhc31hc1ah2a8h668h839h)
X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI
Received: from mail60-am1 (localhost.localdomain [127.0.0.1]) by mail60-am1 (MessageSwitch) id 1327592077807197_3726; Thu, 26 Jan 2012 15:34:37 +0000 (UTC)
Received: from AM1EHSMHS020.bigfish.com (unknown [10.3.201.252])	by mail60-am1.bigfish.com (Postfix) with ESMTP id BF4AA460045; Thu, 26 Jan 2012 15:34:37 +0000 (UTC)
Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS020.bigfish.com (10.3.206.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 26 Jan 2012 15:34:35 +0000
Received: from 011-DB3MPN1-012.MGDPHG.emi.philips.com ([169.254.2.28]) by 011-DB3MMR1-008.MGDPHG.emi.philips.com ([10.128.28.47]) with mapi id 14.01.0355.003; Thu, 26 Jan 2012 15:34:30 +0000
From: "Dijk, Esko" <esko.dijk@philips.com>
To: Carsten Bormann <cabo@tzi.org>, Tom <my.mailing.acc@gmail.com>, "6lowpan@ietf.org" <6lowpan@ietf.org>
Thread-Topic: [6lowpan] ND-17 / DNS support
Thread-Index: AQHM3EAr+L6KwFK3aUmY+mlIgOKtDA==
Date: Thu, 26 Jan 2012 15:35:45 +0000
Message-ID: <031DD135F9160444ABBE3B0C36CED6180595BC@011-DB3MPN1-012.MGDPHG.emi.philips.com>
References: <CAHoqu_oacOGQR+1MbNZJzLQjuDrQ6ZOcs=i6PiNOoF=nwsVhpA@mail.gmail.com> <CAHoqu_pkJ9onU8k2r-3gWEbQmXJTs05zoGtzKqAazZGRxGy5OQ@mail.gmail.com> <054A47D4-276D-44FB-96AD-08BD38BE6521@tzi.org>
In-Reply-To: <054A47D4-276D-44FB-96AD-08BD38BE6521@tzi.org>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [194.171.252.101]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: philips.com
Subject: Re: [6lowpan] ND-17 / DNS support
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: Thu, 26 Jan 2012 15:34:41 -0000

> The same is true for TBD1 (31) and TBD2 (32), which have been assigned in=
 the meantime:
> 31      DNS Search List Option                  [RFC6106]
> 32      Proxy Signature (PS)                    [RFC-ietf-csi-proxy-send-=
05.txt]

#31 triggered me: should 6lowpan-ND mention anything about support of the R=
DNSS option in RFC6106? Supporting would allow 6LBR/6LRs to e.g. distribute=
 an address of a DNS server to all 6LNs. Or are there better alternatives f=
or a 6LN to obtain a DNS server? In many use cases DNS is an essential serv=
ice component, see. e.g. draft-vanderstok-core-bc-05.

Esko

-----Original Message-----
From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf =
Of Carsten Bormann
Sent: Monday 16 January 2012 18:40
To: Tom
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] ND-17

Hi Tom,

(WG chair hat off, individual WG member hat on:)

> 1) Section 5.3 demands "In all cases the RS retransmissions are terminate=
d when a RA is received."
> Is this also applicable when a RA is received with router lifetime is set=
 to zero (e.g a router going down as suggested in rfc4861).

Well, you could consider it to be, but because of the lifetime it then rest=
arts right after 0 seconds...
Yes, something like this could be spelled out.

> 2) TBD4 number (155 XXX) conflicts with the one allocated for RPL.
> Is there a other suggested value or one under common agreement outside ND=
-17 used for interoperability.

The same is true for TBD1 (31) and TBD2 (32), which have been assigned in t=
he meantime:
31      DNS Search List Option                  [RFC6106]
32      Proxy Signature (PS)                    [RFC-ietf-csi-proxy-send-05=
.txt]

These should be relatively painless, but 155 might hurt in interop testing.
Good question, I'll defer to the interop testing community.

> 3) Believe there is a typo here? (page 49, section 12)
> o TBD3 =3D 33
> o TBD4 =3D 155 XXX
> o TBD3 =3D 156 XXX -> Believe this is a typo.

Yes, this is a typo; this should be TBD5.

The numbering of course will be solved once we have actual IANA assignments=
.
Depending on when the spec approval happens, 33 and 156 may also go to othe=
r protocols in the meantime.

I believe we could go for an RFC4020 style early allocation if this uncerta=
inty creates hardships.

Two other observations:
-- we are at ND-18 already.  Please always use the most recent I-D, availab=
le at:

    http://tools.ietf.org/html/draft-ietf-6lowpan-nd

(and now finally with WG chair hat:)

-- please indicate your name on your mailing list messages (I'm assuming th=
at Tom is not your only name, which of course could be the case in several =
locales).

Gr=FC=DFe, Carsten

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan

________________________________
The information contained in this message may be confidential and legally p=
rotected under applicable law. The message is intended solely for the addre=
ssee(s). If you are not the intended recipient, you are hereby notified tha=
t any use, forwarding, dissemination, or reproduction of this message is st=
rictly prohibited and may be unlawful. If you are not the intended recipien=
t, please contact the sender by return e-mail and destroy all copies of the=
 original message.


From cabo@tzi.org  Thu Jan 26 09:24:40 2012
Return-Path: <cabo@tzi.org>
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 CFDCC21F864F for <6lowpan@ietfa.amsl.com>; Thu, 26 Jan 2012 09:24:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 6nmgT+gp0ukN for <6lowpan@ietfa.amsl.com>; Thu, 26 Jan 2012 09:24:40 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5FF21F86C2 for <6lowpan@ietf.org>; Thu, 26 Jan 2012 09:24:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q0QHOWQ9004096; Thu, 26 Jan 2012 18:24:32 +0100 (CET)
Received: from [192.168.217.117] (p5489BC19.dip.t-dialin.net [84.137.188.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 01B6D1DD; Thu, 26 Jan 2012 18:24:31 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <031DD135F9160444ABBE3B0C36CED6180595BC@011-DB3MPN1-012.MGDPHG.emi.philips.com>
Date: Thu, 26 Jan 2012 18:24:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <94580921-D8A8-45B8-9E6E-7D36C9E7969D@tzi.org>
References: <CAHoqu_oacOGQR+1MbNZJzLQjuDrQ6ZOcs=i6PiNOoF=nwsVhpA@mail.gmail.com> <CAHoqu_pkJ9onU8k2r-3gWEbQmXJTs05zoGtzKqAazZGRxGy5OQ@mail.gmail.com> <054A47D4-276D-44FB-96AD-08BD38BE6521@tzi.org> <031DD135F9160444ABBE3B0C36CED6180595BC@011-DB3MPN1-012.MGDPHG.emi.philips.com>
To: "Dijk, Esko" <esko.dijk@philips.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: "6lowpan@ietf.org" <6lowpan@ietf.org>
Subject: Re: [6lowpan] ND-17 / DNS support
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: Thu, 26 Jan 2012 17:24:40 -0000

On Jan 26, 2012, at 16:35, Dijk, Esko wrote:

>> The same is true for TBD1 (31) and TBD2 (32), which have been =
assigned in the meantime:
>> 31      DNS Search List Option                  [RFC6106]
>> 32      Proxy Signature (PS)                    =
[RFC-ietf-csi-proxy-send-05.txt]
>=20
> #31 triggered me: should 6lowpan-ND mention anything about support of =
the RDNSS option in RFC6106?

I don't think so, from my point of view the two are orthogonal (i.e., =
6LoWPAN neither excludes nor optimizes RDNSSO).

(But maybe the way 6LoWPAN-ND and the other ND options fit together is a =
nice subject for a section in the LWIG guidance document.)

> Supporting would allow 6LBR/6LRs to e.g. distribute an address of a =
DNS server to all 6LNs. Or are there better alternatives for a 6LN to =
obtain a DNS server? In many use cases DNS is an essential service =
component, see. e.g. draft-vanderstok-core-bc-05.

*If* your 6LoWPAN nodes need a DNS server, they should get it either =
using RDNSSO (and, heaven forbid, DNSSLO) or, if they are already using =
DHCPv6 for other reasons, using that.
(We at least used to have a sizable group of DHCPv6 fans in the 6LoWPAN =
WG, so I'm not sure we can really recommend either.)

Gr=FC=DFe, Carsten


From johanna.1.nieminen@nokia.com  Thu Jan 26 23:10:53 2012
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 7D18F21F8588 for <6lowpan@ietfa.amsl.com>; Thu, 26 Jan 2012 23:10:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 y0wVcsNhBn8k for <6lowpan@ietfa.amsl.com>; Thu, 26 Jan 2012 23:10:52 -0800 (PST)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id AD4D621F8581 for <6lowpan@ietf.org>; Thu, 26 Jan 2012 23:10:52 -0800 (PST)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0R7A5Jv019988 for <6lowpan@ietf.org>; Fri, 27 Jan 2012 09:10:30 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 27 Jan 2012 09:10:29 +0200
Received: from 008-AM1MPN1-062.mgdnok.nokia.com ([169.254.2.111]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Fri, 27 Jan 2012 08:10:28 +0100
From: <johanna.1.nieminen@nokia.com>
To: <6lowpan@ietf.org>
Thread-Topic: New version of IPv6 over BT-LE draft
Thread-Index: Aczcwr1lMJzwXEp3RYu7InO0T0ccYw==
Date: Fri, 27 Jan 2012 07:10:28 +0000
Message-ID: <5FA713B99ACAA6478C065A155E206B4617688CC4@008-AM1MPN1-062.mgdnok.nokia.com>
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: multipart/alternative; boundary="_000_5FA713B99ACAA6478C065A155E206B4617688CC4008AM1MPN1062mg_"
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Jan 2012 07:10:29.0178 (UTC) FILETIME=[C01CC9A0:01CCDCC2]
X-Nokia-AV: Clean
Subject: [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: Fri, 27 Jan 2012 07:10:53 -0000

--_000_5FA713B99ACAA6478C065A155E206B4617688CC4008AM1MPN1062mg_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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/.

Johanna





--_000_5FA713B99ACAA6478C065A155E206B4617688CC4008AM1MPN1062mg_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left:=
 #800000 2px solid; } --></style>
</head>
<body>
<font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;">
<div>Hi,</div>
<div>&nbsp;</div>
<div>Just to inform that our draft &#8220;Transmission of IPv6 Packets over=
 Bluetooth Low Energy&#8221; was updated some weeks ago based on the WGLC c=
omments. Version 5 is available at:</div>
<div><a href=3D"https://datatracker.ietf.org/doc/draft-ietf-6lowpan-btle/">=
<font color=3D"blue"><u>https://datatracker.ietf.org/doc/draft-ietf-6lowpan=
-btle/</u></font></a>.</div>
<div>&nbsp;</div>
<div><font face=3D"Arial" size=3D"2"><span style=3D"font-size:10pt;">Johann=
a </span></font></div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
</span></font>
</body>
</html>

--_000_5FA713B99ACAA6478C065A155E206B4617688CC4008AM1MPN1062mg_--

From cabo@tzi.org  Fri Jan 27 07:30:35 2012
Return-Path: <cabo@tzi.org>
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 A6CAA21F85F9 for <6lowpan@ietfa.amsl.com>; Fri, 27 Jan 2012 07:30:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 OcgOO+KkY0VU for <6lowpan@ietfa.amsl.com>; Fri, 27 Jan 2012 07:30:35 -0800 (PST)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id CAF2321F85F4 for <6lowpan@ietf.org>; Fri, 27 Jan 2012 07:30:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q0RFUPoH006859; Fri, 27 Jan 2012 16:30:25 +0100 (CET)
Received: from [192.168.217.117] (p5489A116.dip.t-dialin.net [84.137.161.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5734E631; Fri, 27 Jan 2012 16:30:25 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <5FA713B99ACAA6478C065A155E206B4617688CC4@008-AM1MPN1-062.mgdnok.nokia.com>
Date: Fri, 27 Jan 2012 16:30:32 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CC5DECAC-4994-4064-B118-5593332B18E2@tzi.org>
References: <5FA713B99ACAA6478C065A155E206B4617688CC4@008-AM1MPN1-062.mgdnok.nokia.com>
To: <johanna.1.nieminen@nokia.com>
X-Mailer: Apple Mail (2.1251.1)
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: Fri, 27 Jan 2012 15:30:35 -0000

On Jan 27, 2012, at 08:10, <johanna.1.nieminen@nokia.com> wrote:

> Hi,
> =20
> Just to inform that our draft =93Transmission of IPv6 Packets over =
Bluetooth Low Energy=94 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.

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?

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.

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?
-The intro to this section should say that.


Summarizing my observations: =20
a) Whenever the spec leaves a choice, it must either=20
-- 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=FC=DFe, Carsten


From johanna.1.nieminen@nokia.com  Mon Jan 30 00:58:02 2012
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