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

Michael,

Your description captures what I had in mind. In the centralized case, as
part of the joining process (e.g. defined
in draft-richardson-6tisch--security-6top-03), the PCE GETs the CoAP API
version implemented by the newly joining node. The PCE speaks all versions,
and chooses the commands it sends to the node depending on the set of
commands the node understands. Similarly, in a purely distributed cases, a
node GETs the version of the CoAP interface of its neighbor.

In my mind, the version is just a mechanism the CoAP interface offers, and
is generally a "healthy" feature to have, especially if the version of the
interface can change. The initial idea for this discussion is also to be
able to possibly switch to a more generic solution (COMAN? COMI?).

Another versioning option would be to:
- associate a version number to the YANG data model
- have all associated CoAP URIs be prefixed with that version, e.g. /6t/1,
/6t/2, etc.

This is the approach used by Google (
https://developers.google.com/gmail/api/v1/reference/) and Xively (
https://xively.com/dev/docs/api/data/read/single_feed/). It allows for
multiple a node to implement multiple versions, at the cost of an extra
Uri-Path.

Thoughts?

Thomas

On Tue, Nov 11, 2014 at 11:20 AM, Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> 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 =-
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>