Re: [6tisch] CoAP resource management - draft-ietf-6tisch-coap-02

Carsten Bormann <cabo@tzi.org> Tue, 11 November 2014 21:14 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C221ACDD8 for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 13:14:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
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 kKMj4jocXvg2 for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 13:14:42 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 B9A971ACDD7 for <6tisch@ietf.org>; Tue, 11 Nov 2014 13:14:37 -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 mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id sABLEU1o020212; Tue, 11 Nov 2014 22:14:30 +0100 (CET)
Received: from dhcp-9bf8.meeting.ietf.org (dhcp-9bf8.meeting.ietf.org [31.133.155.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7536D8D1; Tue, 11 Nov 2014 22:14:29 +0100 (CET)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <D087B62D.C081%rsudhaak@cisco.com>
Date: Tue, 11 Nov 2014 11:14:26 -1000
X-Mao-Original-Outgoing-Id: 437433266.429945-b39c959477a4b1c84e40f49cd5c00009
Content-Transfer-Encoding: quoted-printable
Message-Id: <27A37719-A535-494C-A3BF-CC8509D35B05@tzi.org>
References: <D0876D12.C03C%rsudhaak@cisco.com> <32412.1415737868@sandelman.ca> <D087B62D.C081%rsudhaak@cisco.com>
To: "Raghuram Sudhaakar (rsudhaak)" <rsudhaak@cisco.com>
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/UGbMqGJ4mXwPBmkl0wMpkxAleKA
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [6tisch] CoAP resource management - draft-ietf-6tisch-coap-02
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Nov 2014 21:14:43 -0000

Version numbers often don’t work very well.
They may look like cheap insurance, but in the end they don’t buy much.
E.g. simply incrementing them suddenly makes you incommunicado with older devices.

Not having looked at the details, I cannot recommend something specific, but maybe e.g. look at the capability indication in draft-ietf-6lo-ghc as a very soft alternative to version numbers.

Grüße, Carsten


> On 11 Nov 2014, at 11:03, Raghuram Sudhaakar (rsudhaak) <rsudhaak@cisco.com> wrote:
> 
> Michael
> I believe ³version data² may be a misleading word I used in the previous
> email. What I meant is the version number.
> 
> The version number uniquely identifies the set of 6top resources that can
> be accessed on a node. Version number is bumped up when a resource is
> added, renamed or deleted.
> 
> Heterogenity may arise when new nodes (running an updated implementation
> which may have added a new resources) are added to existing deployments.
> Heterogenity is entirely w.r.t the version number (and consequently the
> set of 6top resources that can be accessed on the nodes).
> 
> This is important for both the PCE as well as peer nodes to identify what
> information they access on a 6top node.
> 
> -raghuram
> 
> On 11/11/14, 12:31 PM, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:
> 
>> 
>> Raghuram Sudhaakar (rsudhaak) <rsudhaak@cisco.com> wrote:
>>> The third and most important discussion was - 3. How do nodes
>> exchange
>>> the version data (with PCE and other nodes) of nodes so a network of
>>> heterogenous nodes (w.r.t version) can interoperate.  1. Proposal -
>> use
>>> the joining flows defined in
>> draft-richardson-6tisch--security-6top-03
>> 
>>> Comments and suggestions on this proposal are requested.
>> 
>> I don't understand why you talk about "version data"?
>> How are the nodes heterogenous?  I suspect that I might be suffering from
>> unshared terminology here.
>> 
>> -- 
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>> 
>> 
>> 
> 
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
> 
>