IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 11 November 2014 21:20 UTC

Return-Path: <mcr@sandelman.ca>
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 359571ACE1A for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 13:20:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level:
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 mEn2OJ7NakDv for <6tisch@ietfa.amsl.com>; Tue, 11 Nov 2014 13:20:22 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A0E1ACDC5 for <6tisch@ietf.org>; Tue, 11 Nov 2014 13:20:22 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id CC16C20098; Tue, 11 Nov 2014 16:22:25 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 4BEED637F4; Tue, 11 Nov 2014 16:20:21 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 36A58637EA; Tue, 11 Nov 2014 16:20:21 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Raghuram Sudhaakar (rsudhaak)" <rsudhaak@cisco.com>
In-Reply-To: <D087B62D.C081%rsudhaak@cisco.com>
References: <D0876D12.C03C%rsudhaak@cisco.com> <32412.1415737868@sandelman.ca> <D087B62D.C081%rsudhaak@cisco.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Tue, 11 Nov 2014 16:20:21 -0500
Message-ID: <10653.1415740821@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch/EG4_k3fcjfNYqE49YhA_OSMnZ4s
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: Tue, 11 Nov 2014 21:20:24 -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.

-- 
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email