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:[email protected]] Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-375-0556 ext. 237 [email protected]<mailto:[email protected]> www.trilliantinc.com<http://www.trilliantinc.com/> From: 6tisch [mailto:[email protected]] On Behalf Of Thomas Watteyne Sent: 29 juin 2015 03:35 To: [email protected] Cc: [email protected]; 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> wrote: On Fri, Jun 26, 2015 at 3:32 PM, Thomas Watteyne <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/core _______________________________________________ core mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/core
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
