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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 12 November 2014 07:55 UTC

Return-Path: <pthubert@cisco.com>
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 B0CC91A6F68 for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 23:55:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.095
X-Spam-Level:
X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 CJPdFaTucNeV for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 23:55:38 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4959F1A871C for <6tisch@ietf.org>; Tue, 11 Nov 2014 23:55:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1968; q=dns/txt; s=iport; t=1415778940; x=1416988540; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OISNmvUc9OtcSeojIHFpHyf6fR4I1+MUtDYHeF3Eeo8=; b=OSMlDBW3xSNLyNh9YAmTJOcoFsZOkIQw1P4rZtGTuuK1CgETpjv0ZW9G Hzs158whZvqBnSwW/Xc9or3H5jpgvH4fKtmPFcUAx3AsuQqzPjagLbG0/ vN/2/QcYKxHQ/9nUYcuWgb9967Sbvje7frWBTC5wZxODBmsYvXI+4JgmB U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoYIABwSY1StJA2E/2dsb2JhbABcgw6BLQSDAtBwAhx/FgEBAQEBfYQCAQEBAwEjEUUQAgEIGAICBiACAgIwFRACBAENBQiIMAm3OpZKAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EtjCuCWhEBHzEHgnc2gR4FkjqiXoN8bYEPOYEDAQEB
X-IronPort-AV: E=Sophos;i="5.07,367,1413244800"; d="scan'208";a="368349778"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 12 Nov 2014 07:55:39 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sAC7tbHI008898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Nov 2014 07:55:37 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 01:55:37 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "Raghuram Sudhaakar (rsudhaak)" <rsudhaak@cisco.com>
Thread-Topic: [6tisch] CoAP resource management - draft-ietf-6tisch-coap-02
Thread-Index: AQHP/cVQc+aUxQBFuUqRL08yJHRHSZxcReMA//+C4wCAAIrdgIAATJTQ
Date: Wed, 12 Nov 2014 07:55:36 +0000
Deferred-Delivery: Wed, 12 Nov 2014 07:55:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD848A4D4CE@xmb-rcd-x01.cisco.com>
References: <D0876D12.C03C%rsudhaak@cisco.com> <32412.1415737868@sandelman.ca> <D087B62D.C081%rsudhaak@cisco.com> <10653.1415740821@sandelman.ca>
In-Reply-To: <10653.1415740821@sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.210.230]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/-MUPWfa3G5ZA6FstK6jEb3pnsKc
Cc: "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: Wed, 12 Nov 2014 07:55:39 -0000

> 
> 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.
> 
> okay, you mean the version of the 6top API; versions are created by standards
> action...
> 
>     > 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).
> 
> Yes, I agree this is an interesting issue.
> The problem is what do you do when a v2 node tries to talk to a v1 node... we
> need to think about this now, I agree.  I think this is most acute in the minimal
> case, as otherwise the PCE can have a notion about what the range of versions
> available are, and can cope...  The PCE can speak all versions, so this means that
> the nodes do not have to support more than one version.
> But, in the minimal case, they have to talk to each other, so there has to be a
> discovery process and some adaptation.
> 
[PT] 
Exactly

[PT] Pascal