Hi Peter
We seem effectively to be on the same intersection (YANG, CBOR, YANG hash) but still on the opposite side of the street. The core difference seem to be the expected data struture implemented by the CoMI server. All your solutions all based on flat hash table represented below. [cid:[email protected]] All my solutions are all based on a hash table per module context represented below. [cid:[email protected]] This alternate data structure enable a different set of solutions such as: * Access using either the "Data Node ID" alone (if unique) or "Module ID" + "Data Node ID" NOTE: When a clash exist, an alternate "Data Node ID" can be returned by the CoMI server for subsequent requests using the "Data Node ID" alone. * Access to all data nodes of a module NOTE: The CoMI server know which data nodes are part of which module and can return those if a query parameter (select) ask to do so. * Ability to support a mix managed/unmanaged model where some modules may use manage Data Node IDs and others may use YANG hashes NOTE: If we also want to support managed and unmanaged "Module ID", we can use a special character like # to differentiate between them. Module ID prefixed by # can be unmanaged module name, Module ID not prefixed by # can be IANA registered module ID. The advantage will be to minimize the overhead associated to some popular modules. Within a module, all data nodes need to be either manage or unmanaged * Most importantly, this data structure enable different methods which avoid the need to implement a rehash list, its retrieval and storage I'm open to compromise on multiple aspects of the solutions (support of not of managed Module ID, managed Data node ID, specific message format and query parameters). However, I will have hard time to compromise on this fundamental difference. About "OK, but the message overhead argument remains." * On the CoMI server side, I don't consider that adding a dozen of "Module ID" and splitting the hash table in pieces represent an unacceptable overhead, especially if we remove the rehash list. * On the protocol side, if we allow access using the "Data Node ID" alone and if we return an alternate "Data Node ID" in case of a clash for subsequent requests seem to me more efficient than retrieving a rehash list. Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-375-0556 ext. 237 [email protected] www.trilliantinc.com -----Original Message----- From: peter van der Stok [mailto:[email protected]] Sent: 21 mai 2015 05:27 To: Michel Veillette Cc: [email protected]; Andy Bierman; [email protected]; Core Subject: RE: [core] CoMI rehashing Hi Michel, We are not far apart, it seems to me. There is one thing left in my view: - Server returns new hash value to client, or - Client reads new hash value from a supporting file (called "clash-file") The supporting file is introduced to remove storage requirements from server, such as: data node name, name extension, module name, hashes. And it makes rehash handling for large clients (storing the data node names) and for small clients (storing module names only) similar. The "clash-file" is still needed when the server returns the new hash value to store data node name and name extension. By returning the new hash value the server is burdened with the module name storage. few comments below in <pvds2> comment </pvds2> Peter
image001.emz
Description: image001.emz
image003.emz
Description: image003.emz
oledata.mso
Description: oledata.mso
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
