Re: [icnrg] next stepd for draft-zhang-icnrg-icniot-requirements

Marie-Jose Montpetit <marie@mjmontpetit.com> Sat, 17 September 2016 16:05 UTC

Return-Path: <marie@mjmontpetit.com>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497FE12B25C for <icnrg@ietfa.amsl.com>; Sat, 17 Sep 2016 09:05:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mjmontpetit-com.20150623.gappssmtp.com
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 LXPCEM7aT_uK for <icnrg@ietfa.amsl.com>; Sat, 17 Sep 2016 09:05:52 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859F912B161 for <icnrg@irtf.org>; Sat, 17 Sep 2016 09:05:52 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id h8so108542430qka.1 for <icnrg@irtf.org>; Sat, 17 Sep 2016 09:05:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=oSPs/CkbwUeKM4i4IN71kOksKXcr6VzrX02DME6fnOA=; b=P11A2YJ0Je1vkLp0AfsckwCCmCY9SYEO0G1GAZGpM8+dyqPmSLFjqvIjzO5ZXZagAp LetpN3MPli4uOZQMSDA4Kry8pGbKIcxyzcD1CwdRmHSGD2x5p3w6uWvTBJvCUzm2/Bys ntUy4fJgBv0WRV3qK//4hxo6qXf46XjMNRJECgUiUBX75EDCegmyF54TfMpHbyPQpZP+ ANHGXi9r5ovPc7bEOQtoN9PaDFNTLmEN+gk5NH6ZaHJgCIMzE6gfR1MFdV7jQzQ6VXK5 Bc0wvjlMlwNJkqir9v/qfXW+YlzK19BchzzabB4y1SSxuxKYtT1FT/1OUC1wrNFAOFip Wu8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=oSPs/CkbwUeKM4i4IN71kOksKXcr6VzrX02DME6fnOA=; b=mMdycFgomoGPw/m3pAdrc4eJNEwhCyMHervg6EvUJ00Xc6Lh/VSBn712spOBI1V1lF UQGRTJpu2wp4lsq1YyEQVMRrLpEvng/5Kvzn3cjfBbXGRn9vaYmhh3vFIRvfhy206u2/ wFaWafajxLl6k4CogAQQvKDjBfo7KdJ2zXFniryJX90q2XS7sLW66QhA3FuoQWhNszMv KVWvhM+wbnYNpkWvHfbIQLIxEH/BKzBEhLrwd+FNlUjnnkge3EtIMpMYiMncINJJksxc tD6JckA68hcLyOetwgao0iFNa1tmFXVdApRB/W050wL+id3O3XvLJh4xkFw1KaM2NL/2 kjOg==
X-Gm-Message-State: AE9vXwPrlLe+f32GFldLVf/xZPPkPYdjxe6fjLZ3/0JbCAS8/gKeId6zone+FowqPumeOw==
X-Received: by 10.55.89.195 with SMTP id n186mr21350239qkb.275.1474128351362; Sat, 17 Sep 2016 09:05:51 -0700 (PDT)
Received: from ?IPv6:2601:197:401:40c0:ddb9:b9a9:5b64:68b7? ([2601:197:401:40c0:ddb9:b9a9:5b64:68b7]) by smtp.gmail.com with ESMTPSA id w184sm7854591qkw.38.2016.09.17.09.05.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 17 Sep 2016 09:05:50 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_22814C69-DBAA-43A5-9B67-A77B2DFBEC3C"
From: Marie-Jose Montpetit <marie@mjmontpetit.com>
In-Reply-To: <E5891BA9-F809-4830-BA0A-35FDB3837C56@cs.ucla.edu>
Date: Sat, 17 Sep 2016 12:05:49 -0400
Message-Id: <E7B36C2F-89B0-4499-8487-DB5370F5FA31@mjmontpetit.com>
References: <82AB329A76E2484D934BBCA77E9F5249AF4A4A27@PALLENE.office.hd> <E5891BA9-F809-4830-BA0A-35FDB3837C56@cs.ucla.edu>
To: Lixia Zhang <lixia@cs.ucla.edu>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/SzPuvPlRFOXe6E4aTZwt0QE85wk>
Cc: "icnrg@irtf.org" <icnrg@irtf.org>, Dirk Kutscher <Dirk.Kutscher@neclab.eu>
Subject: Re: [icnrg] next stepd for draft-zhang-icnrg-icniot-requirements
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Sep 2016 16:05:55 -0000

I agree with Lixia. This needs more focus. Security is yes weak and should not be an afterthought. But I think the justification of ICN for IOT needs more in-depth descriptions and use cases. I can see many reasons to use ICN in IOT (flexibility in caching, storage and retrieval, naming abstraction, abstracted functionalities) but almost as many reasons not too (added complexity, lack of backward compatibility, firmware development in sensor networks) etc. A few solid examples and I would say solid implementations comparing the advantages of ICN vs. current implementations would be great. Our houses are already filled with IOT apps; how will ICN make them better?

I am not saying the draft is bad. Just that it needs more work before truly reflecting the gains that ICN will bring to IOT.

Marie-José



> On Sep 17, 2016, at 11:54 AM, Lixia Zhang <lixia@cs.ucla.edu> wrote:
> 
> 
>> On Sep 16, 2016, at 9:00 AM, Dirk Kutscher <Dirk.Kutscher@neclab.eu <mailto:Dirk.Kutscher@neclab.eu>> wrote:
>> 
>> Hi all,
>>  
>> This may have fallen between the cracks during the summer break – so this is a friendly reminder:
>>  
>> Please let us have your opinion on how to pursue with this draft. Do you support adopting it as an RG document?
> 
> I just had a quick look over the draft: it seems to me that this draft still left lots rooms for improvements, not the least is its treatment on security.  The current draft seems reflecting the common mindset that security is something one has to mention, not that security is an integral component in all aspects of a system.
> 
> Section 2: would it be more appropriate to move security from section 2.8 to section 2.2, right after naming?  given security needs crypto protection, crypto is directly related to identities
> 
> Section 4 on Advantages of using ICN for IoT has no mentioning about security.
> 
> Section 5, like section 2, puts security discussions much later after  other subjects that may be felt more familiar with, like name resolution, caching and storage, routing/forwarding, etc.--aren't al these components need security as well?
> There seem also discussions on trust that seems separate from security ...
> 
> Another comment is a wish: the draft looks really abstract/motherhood-and-applepie to me, I wonder whether it would be possible to ground the description with some specific examples.
> 
> my 2 cents from a *super* quick flip through (so please take with a big grain of salt!)
> 
> Lixia
>   <>From: Dirk Kutscher 
>> Sent: Montag, 8. August 2016 17:33
>> To: icnrg@irtf.org <mailto:icnrg@irtf.org>
>> Subject: next stepd for draft-zhang-icnrg-icniot-requirements
>>  
>> Hi all,
>>  
>> at the Berlin meeting, we concluded that we’d use the mailing list to agree on next steps for draft-zhang-icnrg-icniot-requirements [1].
>>  
>> In case you don’t remember, this draft is the result of a merger of draft-zhang-iot-icn-challenges-02 [2] and draft-lindgren-icnrg-efficientiot-03 [3], focusing on the scenario, requirements and challenges aspects of both input drafts.
>>  
>> After the merger, the authors have submitted another version, reflecting some community feedback.
>>  
>> Please see https://www.ietf.org/proceedings/96/slides/slides-96-icnrg-3.pdf <https://www.ietf.org/proceedings/96/slides/slides-96-icnrg-3.pdf> for a summary of the genesis and the current content.
>>  
>> The chairs would like to get an understanding whether the ICNRG has an interest in pursuing this draft as a RG activity (“adoption”). We normally do this for drafts where there is a critical mass of interested people that would like to see this progressing within ICNRG and eventually be published as an (in this case, Informational)  RFC. This would also require a critical mass of people that would be interested to spend cycles for reviewing the draft and future revisions.
>>  
>> Could you please let us know whether you think this draft a) should be adopted as a RG item and b) whether you’d be able to help reviewing it?
>>  
>> Thanks,
>> Börje, Dave, Dirk (ICNRG chairs)
>>  
>> [1] https://datatracker.ietf.org/doc/draft-zhang-icnrg-icniot-requirements/ <https://datatracker.ietf.org/doc/draft-zhang-icnrg-icniot-requirements/>
>> [2] https://tools.ietf.org/html/draft-zhang-iot-icn-challenges-02 <https://tools.ietf.org/html/draft-zhang-iot-icn-challenges-02>
>> [3] https://datatracker.ietf.org/doc/draft-lindgren-icnrg-efficientiot/03/ <https://datatracker.ietf.org/doc/draft-lindgren-icnrg-efficientiot/03/>
>>  
>>  
>> _______________________________________________
>> icnrg mailing list
>> icnrg@irtf.org <mailto:icnrg@irtf.org>
>> https://www.irtf.org/mailman/listinfo/icnrg <https://www.irtf.org/mailman/listinfo/icnrg>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg