Subject: [core] CoMI rehashing

From: peter van der Stok <[email-masked]>
Date: Tue, 19 May 2015 09:23:09 +0200

Hi Michel,

Apologies for reacting so late, but we had many discussions which slowly 
converged to the solution described in the attachment.

WE aim at rehashing when a clash occurs.
The client only needs minimal storage space: table with the names of the 
modules.
Per rehash collision, the client only stores old hash, new hash, and 
module identifier

We think that a global module numbering of all relevant modules, 
administrated by IANA, is a large undertaking.
Given the struggle we see elsewhere to save bytes, we think also that we 
should minimize the payload.

Greetings,

Peter

-- 
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: Michel Veillette <[email-masked]>
Date: Tue, 19 May 2015 15:23:37 +0000

Hi Peter

Your propose solution doesn't seem to address YANG hash clashes happening within a YANG module.

Multiple times in your document, you assume that clashes can't happen within a YANG module.
Page 1,  "It is assumed that no clashes occur within one module, and by prefixing a module identifier to the hash, clashing hashes can be distinguished"
Page 3,  "A data node is completely identified by the module identifier and the hash value."

We can probaly make this assumption for YANG modules specifically design for CoMI but this is not true for existing YANG modules and future modules not designed with CoMI in mind.

=======

About "the client creates a "server_table" with entries: <server id, old hash, M_id, new hash> "

Let say we have the following two data nodes:
   /sys:system-state/sys:clock/sys:current-datetime, 355927048
   /sys:system-state/sys:clock/sys:boot-datetime, 355927048

Having the following table within the client is not sufficient to distinguate between the "current-datetime" and the "boot-datetime".
   fe80::200:f8ff:fe21:67cf, 355927048, ietf-system, 783481403
   fe80::200:f8ff:fe21:67cf, 355927048, ietf-system, 530731873

========

Introducing the concept of "hash clash" error help to avoid the need to retreive the "clash_file" when no clashes exist.
However, if we agree that clashes may exist within a YANG module, we are back to square one with the original rehashing mechanism.

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]
www.trilliantinc.com   

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: 19 mai 2015 03:23
To: Michel Veillette
Cc: Core; [email-masked]
Subject: CoMI rehashing

Hi Michel,

Apologies for reacting so late, but we had many discussions which slowly converged to the solution described in the attachment.

WE aim at rehashing when a clash occurs.
The client only needs minimal storage space: table with the names of the modules.
Per rehash collision, the client only stores old hash, new hash, and module identifier

We think that a global module numbering of all relevant modules, administrated by IANA, is a large undertaking.
Given the struggle we see elsewhere to save bytes, we think also that we should minimize the payload.

Greetings,

Peter

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 May 2015 08:35:16 -0700

> We can probaly make this assumption for YANG modules specifically design for CoMI but this is not true for existing YANG modules and future modules not designed with CoMI in mind.

Dos this mean you have identified existing YANG modules
that would have multiple nodes with the same hash value?
I have not found any so far.

IMO it is much more reasonable to make sure that a YANG module
intended for use in CoMI does not have any clashes.

>    /sys:system-state/sys:clock/sys:boot-datetime, 355927048

But these are the wrong hash values.

>    fe80::200:f8ff:fe21:67cf, 355927048, ietf-system, 530731873

The assumption is that modules for CoMI will be checked for hash collisions,
and the module will be altered to remove any collisions.  Since a module
has about 100 nodes in it and it takes about 70,000 nodes for a 50%
chance at a collision, it will be quite easy to prevent clashes in a
single module.

Andy

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Michel Veillette <[email-masked]>
Date: Tue, 19 May 2015 15:47:39 +0000

Hi Andy

No, I didn’t try to investigate if YANG hash clashes within existing modules exist.
Multiple of them of proprietary and doing an extensive search is not practical.

The point is not to determine if such clashes exist but how the protocol will handle them if they do exist.
The current answer seem to be bad luck, try again, your module can't be implemented using CoMI. 

Michel Veillette

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: 19 mai 2015 11:35
To: Michel Veillette
Cc: [email-masked]; [email-masked]; Core
Subject: Re: [core] CoMI rehashing

> We can probaly make this assumption for YANG modules specifically design for CoMI but this is not true for existing YANG modules and future modules not designed with CoMI in mind.

Dos this mean you have identified existing YANG modules that would have multiple nodes with the same hash value?
I have not found any so far.

IMO it is much more reasonable to make sure that a YANG module intended for use in CoMI does not have any clashes.

>    fe80::200:f8ff:fe21:67cf, 355927048, ietf-system, 530731873

The assumption is that modules for CoMI will be checked for hash collisions, and the module will be altered to remove any collisions.  Since a module has about 100 nodes in it and it takes about 70,000 nodes for a 50% chance at a collision, it will be quite easy to prevent clashes in a single module.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 May 2015 11:34:09 -0700

> The current answer seem to be bad luck, try again, your module can't be implemented using CoMI.

It is difficult to believe that a 6TISCH CoMI device is too small to
store 16K of strings, but it will be powerful enough to run YANG
modules intended for NETCONF devices such as routers.

There is a very small chance that a module in progress has
hash collisions in it, and the name of a node has to be changed
to fix it (before the module is published).
IMO this is the least painful solution.

Andy

---

From: Michel Veillette <[email-masked]>
Date: Tue, 19 May 2015 19:49:16 +0000

Hi Andy, Hi Peter

A solution based on the use of "module ID, YANG hash" as unique identifier seem to be promising.
If we can successfully address the items bellow (1 to 3), I believe we can address the different issues identified without introducing a module ID registry.
Something I agree it will be nice to avoid.

Issues:
- "clash_file" on the server side
- traffic overhead (handshake to retrieve the "clash_file")
- per-server rehash table overhead on the client side
- string table overhead on the client side to index the "clash_file"

ITEM 1) Hash clashes within a YANG module

We need to describe one or multiple approaches to resolve YANG hash clashes within a module if this ever happen.
- We can suggest to rename any conflicting data node identifier(s) prior publishing
- We can introduce a new YANG statement to assign an alternate hash value to an already published YANG module
- We can also setup a registry to publish alternate hash values to an already published YANG module

ITEM 2)  Traffic overhead

The propose hash clash error is a step in the right direction to avoid the upfront retrieval of the "clash_file". To completely eliminate the need to retrieve the "clash_file" , I propose to support the "module name" as an optional query parameter. This option can be used to access the targeted data node after receiving a hash clashes error or to avoid hash clashes errors.

For example:
   To retrieve data nodes "current-datetime" and  "boot-datetime"

   Option #1 
      REQ: GET example.com/mg?select= VNwQI,folNh
      (This request may return a hash clash error)

   Option #2
      REQ: GET example.com/mg?select=ietf-system(VNwQI,folNh)
      (This request never return a hash clash error)

ITEM 3) Datastore access

Access (GET and PUT) of  the entire datastore is an important feature to allows backup and restoration of a device configuration. To resolve hash clashes between modules, I propose to support the concept of module context as describe in my document (draft-vanderstok-core-comi-06 - MV.docx).

For example:

   REQ: GET example.com/mg

   RES: 2.05 Content (Content-Format: application/cbor)
   {
      "module a" : {
         365257235 : value
         702149626 : {
            215993329 : value            <--- hash clashes
            962191682 : value
         },
         829222983 : value
      },
      "module b" : {
         215993329 : value               <--- hash clashes
      },
      "module c" : {
         993533527 : value
      }
   }

I hope this approach represents a win/win solution which avoid the two contentious items:
- IANA module ID registration
- rehash and "clash_file"

In summary:
In this solution there is no more rehash value, no "clash_file".
We just use the "module ID, YANG hash" as unique identifier.
Message size overhead is keep to a minimum and this overhead is optional (at the exception of the datastore access).

Michel Veillette

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: 19 mai 2015 14:34
To: Michel Veillette
Cc: [email-masked]; [email-masked]; Core
Subject: Re: [core] CoMI rehashing

> The current answer seem to be bad luck, try again, your module can't be implemented using CoMI.

It is difficult to believe that a 6TISCH CoMI device is too small to store 16K of strings, but it will be powerful enough to run YANG modules intended for NETCONF devices such as routers.

There is a very small chance that a module in progress has hash collisions in it, and the name of a node has to be changed to fix it (before the module is published).
IMO this is the least painful solution.

Andy

---

From: peter van der Stok <[email-masked]>
Date: Wed, 20 May 2015 08:54:09 +0200

Hi Michel,

When clashes can exist within a module, indeed the intended data node 
cannot be determined from the hash value and the module name.
We all agree about that.
If a clash happens within a module, the original data node names need to 
be stored in the client.
The new hash value can be found by inspecting the clash-file.

In conclusion:
(1) when no clashes occur within a module it is sufficient to store the 
module name and information per clash per server in the client.
(2) When clashes occur in a module, also the names of the clashing data 
nodes need to be stored in the client.
(3) When no clashes at all occur, no storage space is needed in the 
client.
Condition (1) produces acceptable overhead IMO.
condition (2) should be avoided but can be handled by the protocol
condition (3) may well be the norm in most cases.

Peter

Michel Veillette schreef op 2015-05-19 17:23:
> Page 1,  "It is assumed that no clashes occur within one module, and
> by prefixing a module identifier to the hash, clashing hashes can be
> distinguished"
> We can probaly make this assumption for YANG modules specifically
> design for CoMI but this is not true for existing YANG modules and
> future modules not designed with CoMI in mind.
> 
> =======
> 
> Having the following table within the client is not sufficient to
> distinguate between the "current-datetime" and the "boot-datetime".
> Introducing the concept of "hash clash" error help to avoid the need
> to retreive the "clash_file" when no clashes exist.
> However, if we agree that clashes may exist within a YANG module, we
> are back to square one with the original rehashing mechanism.
> 
> Michel Veillette
> Apologies for reacting so late, but we had many discussions which
> slowly converged to the solution described in the attachment.
>

---

From: peter van der Stok <[email-masked]>
Date: Wed, 20 May 2015 12:15:05 +0200

Hi Michel,

see below, some preliminary comments.

Peter

Michel Veillette schreef op 2015-05-19 21:49:
> If we can successfully address the items bellow (1 to 3), I believe we
> can address the different issues identified without introducing a
> module ID registry.
<pvds>
Nice to know that we are on the same track
</pvds>
> We need to describe one or multiple approaches to resolve YANG hash
> clashes within a module if this ever happen.
> - We can introduce a new YANG statement to assign an alternate hash
> value to an already published YANG module

<pvds>
Is this a subject for CoMI draft?
May be address this in another draft?
</pvds>

> 
> ITEM 2)  Traffic overhead
> 
> The propose hash clash error is a step in the right direction to avoid
> the upfront retrieval of the "clash_file".
<pvds>
The reason is different; I was worried about upgrades of servers, the 
specification left open that the old hash value of a data_node was 
rehashed,
and a new data-node with the original hash was added.
Clients could then access another data node with the old hash value.
</pvds>
> To completely eliminate the
> need to retrieve the "clash_file" , I propose to support the "module
> name" as an optional query parameter. This option can be used to
> access the targeted data node after receiving a hash clashes error or
> to avoid hash clashes errors.
> 
> For example:
<pvds>

Your proposal increases data traffic permanently when a clash has 
occurred,
and needs the storage of module names in server as well.

With rehashing, the "clash_file" overhead happens only once after the 
reload of the server.

BTW the /mg string in URI is removed when possible.
</pvds>
> ITEM 3) Datastore access
> 
> Access (GET and PUT) of  the entire datastore is an important feature
> to allows backup and restoration of a device configuration.
<pvds>
You mean server or client, or both?
and what is device configuration? the set of data nodes that are 
accessible, or the values of all accessible data-nodes?
</pvds>
> To resolve
> hash clashes between modules, I propose to support the concept of
> module context as describe in my document
> (draft-vanderstok-core-comi-06 - MV.docx).
> 
> For example:
> 
>    REQ: GET example.com/mg
> 
<pvds>
Do you want a dump of all values of all accessible data nodes?
The proposed syntax does not logically follow from ITEM 2), because 
rehashing is compulsory, and you will have two hashes pointing to the 
same value belonging to the same data node.
When using rehashing, a (smaller) flat table with "hash value : data 
node value" is returned.
Alternatively, I can see a request that returns for all clashed hashes 
the information: old hash, module name, new hash; but that means storing 
module names in server as well.
</pvds>

> - rehash and "clash_file"
<pvds>
The "clash-file" is only accessed by a client when a reload of the 
server (how often does that happen?) leads to hash clash (probability < 
10^-4)
</pvds>
> We just use the "module name, YANG hash" as unique identifier.
<pvds>
This is then optional next to the compulsory rehashing?
</pvds>
> Message size overhead is keep to a minimum and this overhead is
> optional (at the exception of the datastore access).
> 
> Michel Veillette

---

From: Michel Veillette <[email-masked]>
Date: Wed, 20 May 2015 15:46:57 +0000

[MV] Inline

Michel Veillette

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]] 
Sent: 20 mai 2015 06:15
To: Michel Veillette
Cc: Andy Bierman; [email-masked]; [email-masked]; Core
Subject: RE: [core] CoMI rehashing

Hi Michel,

Peter

> Something I agree it will be nice to avoid.

<pvds>
Nice to know that we are on the same track </pvds>

<pvds>

[MV] Minimally, the strategy used to address internal module clashes should be described clearly in the CoMI spec.

> the upfront retrieval of the "clash_file".

<pvds>
The reason is different; I was worried about upgrades of servers, the specification left open that the old hash value of a data_node was rehashed, and a new data-node with the original hash was added.
Clients could then access another data node with the old hash value.
</pvds>

[MV] The side effect of not requiring upfront loading of the "rehash" list is nice feature.

<pvds>

Your proposal increases data traffic permanently when a clash has occurred, and needs the storage of module names in server as well.

With rehashing, the "clash_file" overhead happens only once after the reload of the server.

[MV] This overhead is not necessary permanent.
[MV] The CoMI server may return a rehash value in the payload which can be used for subsequent accesses.
[MV] This way, we cut the extra exchange and the state machine associated with it.

<pvds>
You mean server or client, or both?
and what is device configuration? the set of data nodes that are accessible, or the values of all accessible data-nodes?
</pvds>

<pvds>

[MV] Yes, backup and recovery this is a core feature of NETCONF and should be supported at lower scale using CoMI

The proposed syntax does not logically follow from ITEM 2), because rehashing is compulsory, and you will have two hashes pointing to the same value belonging to the same data node.

[MV] I the model I'm proposing, each module have its own hash table, both the "module name" + "hash value" is used to identify a data node.

When using rehashing, a (smaller) flat table with "hash value : data node value" is returned.
Alternatively, I can see a request that returns for all clashed hashes the information: old hash, module name, new hash; but that means storing module names in server as well.
</pvds>

> - rehash and "clash_file"

<pvds>
The "clash-file" is only accessed by a client when a reload of the server (how often does that happen?) leads to hash clash (probability <
10^-4)
</pvds>

<pvds>

---

From: peter van der Stok <[email-masked]>
Date: Thu, 21 May 2015 11:27:14 +0200

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

Michel Veillette schreef op 2015-05-20 17:46:
> [MV] Minimally, the strategy used to address internal module clashes
> should be described clearly in the CoMI spec.
> 
>> 
>> ITEM 2)  Traffic overhead
>> 
> rehashed, and a new data-node with the original hash was added.
<pvds2>
Some text in the draft is needed anyway to motivate the CoMI re-hash 
specification
</pvds2>
> occurred, and needs the storage of module names in server as well.
> 
<pvds2>
Interesting.
But somewhere the rehash needs to be done
Not clear what this means in message exchanges
</pvds2>
> [MV] Yes, backup and recovery this is a core feature of NETCONF and
> should be supported at lower scale using CoMI
> 
> [MV] I the model I'm proposing, each module have its own hash table,
> both the "module name" + "hash value" is used to identify a data node.
<pvds2>
OK, but the message overhead argument remains. The CoMI design criterion 
is to produce small message sizes and small servers.
You rightly also introduced the concern for storage space in clients.
Actually our table examples are there to show feasibility and explore 
table info needs.
A server or client is free to structure tables as it wishes.
</pvds2>
> the information: old hash, module name, new hash; but that means
> storing module names in server as well.
> </pvds>
>

---

From: Michel Veillette <[email-masked]>
Date: Thu, 21 May 2015 16:32:04 +0000

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.

All my solutions are all based on a hash table per module context represented below.

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

Trilliant Inc.

www.trilliantinc.com

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]]
Sent: 21 mai 2015 05:27
To: Michel Veillette
Cc: [email-masked]; Andy Bierman; [email-masked]; Core
Subject: RE: [core] CoMI rehashing

Hi Michel,

"clash-file")

The supporting file is introduced to remove storage requirements from server, such as: data node name, name extension, module name, hashes.

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 21 May 2015 17:03:01 -0700

On Thu, May 21, 2015 at 9:32 AM, Michel Veillette <
[email-masked]> wrote:

>  Hi Peter
>
>
>
> We seem effectively to be on the same intersection (YANG, CBOR, YANG hash)
>  but still on the opposite side of the street.
>

Both solutions rely equally on the YANG module writer to solve any hash
clashes
within 1 module.  The advantage of a module-id is that if this is done, no
re-hash
is needed at all. How is a Data Node ID encoded? Not sure how that works.

The cost of the module-id is really in the message encoding.

What if the protocol allowed the client to discover a set of module-name
to local-module-number mappings that can be used as the module-id
in messages?

The client has to store the module name anyway (that is 'Module ID'
since modules are not assigned numbers).  The extra storage
is 1 number (16 bits?) per module, per server. Maybe 32 bytes per server.
Would that be too much?

I would like the module-id approach if the encoding was a number instead
of a string.

Andy

> ·         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.
> ·         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).
>
> 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
>

---

From: Michel Veillette <[email-masked]>
Date: Fri, 22 May 2015 13:40:07 +0000

Hi Andy

See [MV] Inline

Both solutions rely equally on the YANG module writer to solve any hash clashes
within 1 module.  The advantage of a module-id is that if this is done, no re-hash
is needed at all. How is a Data Node ID encoded? Not sure how that works.

[MV]
The Data Node ID is a integer, I changed the name to open the door to the support of both managed and unmanaged ID.
For module implementing unmanaged IDs, this integer contains the current 30 bits mm3 hash.
For module implementing managed IDs, this integer contains an assigned ID.
This feature can be used to reduce significantly the payload size (~50%)
Another possible application is the mapping of Zigbee ZCL clusters to CoMI modules while keeping the same attribute (Data Node) ID.
This is not a mandatory feature but there is not much efforts required to support this since both approaches use integers, we just need to add some description texts.

[MV] If we still support access with the Data Node ID only with the possibility to receive a clash error, this overhead is optional.

For example:
REQ: GET example.com/mg/VNwQI                              // May return a clash error
REQ: GET example.com/mg/?select=ietf-system    // Never return a clash error

Or this alternate approach if we want to support the retrieval of multiple data nodes:
REQ: GET example.com/mg? select=VNwQI,folNh                             // May return a clash error
REQ: GET example.com/mg/?select=ietf-system(VNwQI,folNh)  // Never return a clash error

[MV] Cool idea, this is a nice alternative to a registry.
Can we use /.well-known/core to implement this feature?

If we do so, I think that both the module name and a module ID should be supported.
This way, this extra handshake use to retrieve these module IDs can be skipped when this optimization is not required by the client (Short interactions or larger frame supported)

[MV] Seem reasonable

[MV] As mentioned above, I thing we should support both.

Andy

Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email-masked]<mailto:[email-masked]>
www.trilliantinc.com<http://www.trilliantinc.com/>

Sent: 21 mai 2015 20:03

On Thu, May 21, 2015 at 9:32 AM, Michel Veillette <[email-masked]<mailto:[email-masked]>> wrote:

Hi Peter

•         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).

•         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

Trilliant Inc.

[email-masked]<mailto:[email-masked]>

www.trilliantinc.com<http://www.trilliantinc.com>

-----Original Message-----
From: peter van der Stok [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 21 mai 2015 05:27
To: Michel Veillette
Cc: [email-masked]<mailto:[email-masked]>; Andy Bierman; [email-masked]<mailto:[email-masked]>; Core
Subject: RE: [core] CoMI rehashing

Hi Michel,

"clash-file")

few comments below in

<pvds2> comment </pvds2>

Peter