Re: [core] CBOR Encoding of Data Modeled with YANG

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Dec 08, 2015 at 01:34:24PM +0100, Carsten Bormann wrote:
> Juergen Schoenwaelder wrote:
> > I want independently developed systems to interoperate. In general, I
> > can't assume modules have data node IDs (since a YANG module like lets
> > say ietf-interfaces simply does not define them).
> 
> One discussion we haven't had is whether we can combine COMI-style
> identifier hashing as the general solution with optional use of manually
> managed identifiers.  This would give us the coverage of "any item from
> any YANG module" that we would like to have, but still provide the
> opportunity for more optimization in specific modules that can benefit
> from tighter representation (including the external/internal identifier
> split), which we might be able to subject to a tighter development regime.
>

I prefer one solution instead of multiple solutions. I think we should
try to understand the pros/cons of the various possible solutions and
try to take an informed decision.

The solution space is even bigger than the two proposals on the table.
For example, an implementation could simply use locally assigned data
node IDs and publish a dictionary mapping names to data node ids. Yes,
there are downsides with this as well. (Or, as a variation, you
include the dictionary in the encoding, then it looks a bit like
compression.)

So far, the decision tree I have in my mind roughly looks like this:

a) use identifier strings (+simple, -verbose)
b) use data node identifiers (-more complex, +compact)
   b1) derive data node identifiers algorithmically from YANG data models
       (-might be tricky in certain cases)
   b2) use a hash algorithm to derive data node identifiers from the set of
       announced YANG data models
       (-need to deal with hash collisions, slightly larger numbers)
   b3) use locally assigned data node identifiers and provide a cachable
       mapping dictionary
       (-different data node identifiers for each device, data without
         dictionary is meaningless)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>