Re: [core] [6tisch] [CoMI] multiple operations in a single request

[Michel Veillette <[e-mail]>]

Hi Thomas

To facilitate the creation of this encoding, can you provide an example of what you want to archive using SQL style statement for example.

For example:

INSERT INTO CellList
   (CellID, SlotframeID, SlotOffset, ChannelOffset, LinkOption, LinkType, CellType, NodeAddress, TrackID)
VALUES
   (1, 0, 2, 5, 0x01, 0, 0, ?leafref);

Couple of comments:

·         CellID

The  CellID need to be unique since it’s the key within the CellList.

How the assignment of CellIDs  is expected to be done?

To be unique, should the server assign this value and return the value assigned to the client? (This might require the use of a RPC)

·         TrackID

Currently, the TrackID is implemented using the datatype leafref which is not supported by the current COMI draft

·         draft-vanderstok-core-patch-00

The current draft introducing patch don’t seem to allow multiple insertion within a list. If this is not the case, It will be nice to have an example added to this draft.

[cid:[e-mail]0BB7E0]

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: [phone] ext. 237
[e-mail]<mailto:[e-mail]>
www.trilliantinc.com<http://www.trilliantinc.com/>



From: 6tisch [mailto:[e-mail]] On Behalf Of Thomas Watteyne
Sent: 29 juin 2015 03:35
To: [e-mail]
Cc: [e-mail]; Andy Bierman; core
Subject: Re: [6tisch] [core] [CoMI] multiple operations in a single request

Peter,
Thanks. I'm looking forward to "counting bytes" and see how compact a PATCH operation is represented in CoMI.
Thomas

On Mon, Jun 29, 2015 at 9:01 AM, peter van der Stok <[e-mail]<mailto:[e-mail]>> wrote:
Hi Thomas,

the latest (not published yet) version includes the use of the PATCH command.
There is a RFC on JSON patch, we could refer to that in the PATCH I-D.
Further link-format is sufficient, no?

The number of items in the payload depends on the the server.
If large strings need to be replaced, the size is quickly large.

I was thinking of just using JSON CBOR with payloads like:

{ hash1: value1,
hash2: value2}

and changing individual list items.

I don't know about YANG PATCH media type.

Peter

Thomas Watteyne schreef op 2015-06-27 10:49:

Andy,

Thanks. https://tools.ietf.org/html/draft-vanderstok-core-comi-06 now
says:

[p4] TODO: Introduce CoAP Patch options to allow modification to
subsets of resource.

[p24] TODO: Define where PATCH is needed.

I assume that you are introducing PATCH in -07. Can you quantify how
lightweight this will be, e.g. how many cells can I add/remove in a
single packet?

Thomas

On Sat, Jun 27, 2015 at 12:51 AM, Andy Bierman <[e-mail]<mailto:[e-mail]>>
wrote:
On Fri, Jun 26, 2015 at 3:32 PM, Thomas Watteyne
<[e-mail]<mailto:[e-mail]>> wrote:
In the 6TiSCH context, CoMI can be used to manage a TSCH schedule,
which involves adding/removing cells (atomic layer 2 resources).

Cells are represented in the 6top YANG model as a list called
"CellList"

(https://tools.ietf.org/html/draft-ietf-6tisch-6top-interface-03#section-4.1).
The way CoMI is written now (draft-vanderstok-core-comi-06), one
CoMI request is needed for each operation. That is, if I want to
schedule 10 cells between nodes A and B, I will need 10 PUT
requests to node A, and 10 to node B. If these are confirmable
CoAP packets, that's a lot of packets. These will be short
requests, but will eat up an enormous amount of bandwidth.

I'd like to be able to issue a single request to node A and a
single request to node B to carry out all of these operations, by
aggregating multiple "operations" in a single CoMI request (a
single/small number of CoAP packets).

What does CoMI offer me today to do this? Should we write the YANG
model in some particular way? What is envisioned in a future
revision of CoMI to answer this need.

I think the YANG Patch media type could be used with CoMI.
This allows multiple edits on different target resources.

You could also do a plain PATCH on the datastore root, and provide
the subtrees you want to change.
Thanks,
Thomas

Andy
_______________________________________________
core mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/core


_______________________________________________
core mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/core