[icnrg] fixed header self-declaration (was Re: Fwd: New Version Notification for draft-lindgren-icnrg-efficientiot-02.txt

christian.tschudin@unibas.ch Thu, 08 January 2015 21:03 UTC

Return-Path: <christian.tschudin@unibas.ch>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEE81A1B3C for <icnrg@ietfa.amsl.com>; Thu, 8 Jan 2015 13:03:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 39QVg0nletJP for <icnrg@ietfa.amsl.com>; Thu, 8 Jan 2015 13:03:54 -0800 (PST)
Received: from mx1-priv.urz.unibas.ch (mx1-priv.urz.unibas.ch [131.152.226.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B4E1A1B14 for <icnrg@irtf.org>; Thu, 8 Jan 2015 13:03:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx1-priv.urz.unibas.ch (Postfix) with ESMTP id 888903E0167; Thu, 8 Jan 2015 22:03:51 +0100 (CET)
X-Virus-Scanned: amavisd-new at unibas.ch
Received: from mx1-priv.urz.unibas.ch ([131.152.226.164]) by localhost (mx1-mgnt.urz.unibas.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nQq6ldaA--8i; Thu, 8 Jan 2015 22:03:51 +0100 (CET)
Received: from cs-meet.cs.unibas.ch (cs-meet.cs.unibas.ch [131.152.55.199]) by mx1-priv.urz.unibas.ch (Postfix) with ESMTPS id 752E73E0162; Thu, 8 Jan 2015 22:03:51 +0100 (CET)
Date: Thu, 08 Jan 2015 22:03:51 +0100
From: christian.tschudin@unibas.ch
X-X-Sender: tschudin@cs-meet.cs.unibas.ch
To: Mark Stapp <mjs@cisco.com>
In-Reply-To: <54AEBA9F.7000508@cisco.com>
Message-ID: <alpine.DEB.2.02.1501082128170.3580@cs-meet.cs.unibas.ch>
References: <20150108115700.6538.91253.idtracker@ietfa.amsl.com> <794B8A00-BB9E-487D-8CD1-1F3591EC5C26@sics.se> <alpine.DEB.2.02.1501081559240.29267@cs-meet.cs.unibas.ch> <54AEBA9F.7000508@cisco.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Archived-At: <http://mailarchive.ietf.org/arch/msg/icnrg/qCUhb3X_Kth3j3NLvsWb876FVaY>
Cc: icnrg@irtf.org
Subject: [icnrg] fixed header self-declaration (was Re: Fwd: New Version Notification for draft-lindgren-icnrg-efficientiot-02.txt
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.15
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: <http://www.irtf.org/mail-archive/web/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: Thu, 08 Jan 2015 21:03:58 -0000

On Thu, 8 Jan 2015, Mark Stapp wrote:

> hmm: I think this is a bit strong:
...
> I appreciate your advocacy for "named functions", but that capability seems 
> to me to be one of the various interesting services that an ICN-ish network 
> might support. I'm not convinced that the concept needs to be included in 
> every discussion or accomodated as a core property.

point taken, no problem. Suggesting that I ask for "accomodation as a 
core property" might be strong, too? ;-)

However, I consent with the extremist label for myself when it comes to 
multi-protocol support. For example, I would be very much in favor of 
self-declaration in form of an additional type field in the fixed header 
saying "I'm carrying ccnb stuff", "I'm cisco2015", "I'm NDN". This would 
clarify what the version field is about: it's the version of the fixed 
header and nothing more, not the version of the carried protocol data 
units.

Views?

best, christian


> I don't think this is "tyranny" or even "extreme". CCN/NDN has a couple of 
> core properties, and we're trying to discover whether those properties 
> compose a system that actually ... works. getting some focussed discussion on 
> what is actually in a name, for example, seems ... far from "extreme" to me. 
> it is not glamorous to be sure, to ask folks to say "we have to have 
> such-and-such available" or "we must NOT have such-and-such", and to ask them 
> to write that down, and support those assertions. but I think that's a good 
> way to highlight the underlying assumptions and semantic issues about what 
> NDN can express, and how.
>
> -- Mark