Subject: [6tisch] Ambiguous identifiers on the CoMI client side

From: Michel Veillette <[email-masked]>
Date: Thu, 25 Jun 2015 16:18:01 +0000

The current COMI draft seem to be based on the assumption that CoMI clients and CoMI servers share the same identifier space. In real life, centralized CoMI client (e.g. NMS) can implement a much larger number of objects and constrained CoMI clients can implement a similar size but different set of objects.

The following two example show some of the issues raised by these scenarios.

Example #1:

In this example, a sever implement YANG module A and B and a client implement module A and C.
Module B and C have a YANG clash but since the server don't implement these two modules, no rehash are created.

If the client send a GET of YANG hash 727582530 (Object in Module C), the server will return an object in Module B instead of generating a Not Found error.
The client will process this Module B object assuming it's a Module C object.

Example #2:

In the previous example, we might say that CoMI clients need at least to know the list of modules implemented by target CoMI servers and not request objects not part of this list. Is this really fix the issue?

In this second example, the client and the server implement the same modules, A and B.
However, not all objects are mandatory and the server implement the top part of these modules, the client implement the lower part.

The client request YANG hash 727582530 from module B and receive an object from module A.

The only viable solution to this issue seem to make the list of objects implemented by CoMI servers (YANG path, YANG hash) available to CoMI clients.
Not sure we still are in the domain of constrained devices however.

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/>