Re: [Lwip] The LWIG Challenge

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 04 July 2014 18:45 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096EC1B2EB9 for <lwip@ietfa.amsl.com>; Fri, 4 Jul 2014 11:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRcCd_I1iAQv for <lwip@ietfa.amsl.com>; Fri, 4 Jul 2014 11:45:22 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039FD1B2EBE for <lwip@ietf.org>; Fri, 4 Jul 2014 11:45:17 -0700 (PDT)
Received: from [192.168.131.128] ([80.92.115.50]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MCLQ1-1WuZtO0Pqb-0095uK; Fri, 04 Jul 2014 20:45:11 +0200
Message-ID: <53B6F634.90209@gmx.net>
Date: Fri, 04 Jul 2014 20:45:08 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Cao, Zhen (CZ)" <caozhen@chinamobile.com>, lwip@ietf.org
References: <53B515B2.2080402@gmx.net> <017b01cf976c$d0b5a0e0$7220e2a0$@chinamobile.com> <53B67F31.5070108@gmx.net> <01a101cf977b$620610d0$26123270$@chinamobile.com>
In-Reply-To: <01a101cf977b$620610d0$26123270$@chinamobile.com>
X-Enigmail-Version: 1.5.2
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="nLEeFt4pwjspJK61wKnOvPJ7laXej3KQ0"
X-Provags-ID: V03:K0:fqAtwFhEvoi4yOTtTkBoXvXbT3/svO4AqCrnmuNaE/JDMoFBEwp jJxlKeS4iM9osmNvBYaPFb01O6HD4QphQEvlbuFLWSNKgpeI6Yy0xytOglmcD1VN72F/3+2 ZhmHAiSj+czkQnfkHpaapb7x8KwGrGD4Lx5wIzDPCZ1myWBnupfx0BdHiU0E34SdGn44cl8 4NcYZcjEcMiYWSGdSU0MQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/lwip/L8by5BAyWze2TAcILScxf4HySjA
Subject: Re: [Lwip] The LWIG Challenge
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Lightweight IP stack <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jul 2014 18:45:25 -0000

Hi Cao,

On 07/04/2014 01:30 PM, Cao, Zhen (CZ) wrote:
> At least for example, using of send-only model for sleeping nodes to
> save energy. Need of eliminating the role or acting as a COAP server
> or Waiting for COAP observation subscriptions.

I think that this issue could be described independent of any radio
technology. At least right now there is nothing in there that makes it
radio technology specific.

I have just submitted an updated version of the IAB Smart Object
Architecture document and included a section on design patterns (see
Section 2 of
http://www.ietf.org/internet-drafts/draft-iab-smart-object-architecture-04.txt).


I am convinced that we need to have stories about the standards we
believe should be used in each of these scenarios. Even for the simplest
scenario (device-to-cloud) we do not yet have a complete story.

If we could produce documents that specifically refer to these scenarios
and discuss a specific concern (such as security or energy efficiency)
that might get us somewhere. For DTLS-based security that's what I am
trying to do, as mentioned at the last IETF meeting. I am not yet there
since I am still getting the "paper-work" done in with the DTLS profile
document in the DICE working group. Note also that the DTLS profile
draft only focuses on the device-to-cloud use case - nothing else (and
that's already complex enough).

Ciao
Hannes