Hi Michel,
short answers in text.
===== About this concept of "handle table generation off-line".
I don’t understand how this approach work, this seem a chicken and egg
issue
The table need to have:
- A identifier of a peer CoMI server (IPv6 address)
- The rehash value use on this server (Unsigned 32 bits)
- The identifier of the attribute affected (If not the canonical
representation of the path identifier, what it is?)
Considering also the number of peer CoMI servers in some application
space (thousands of peers in a NAN network for example), I don't see
this as a viable solution.
To be certain: we talk about very small clients with no storage space
for YANG names or host names.
Let's agree to disagree:
To me: Administrating in the this client 1-2 groups of servers with 1-2
re-hashes looks like a much smaller problem (at least in storage size)
than
the already compulsory administering in the client of
thousands (probably changing) IPv6 addresses of servers and their
associated (also changing) YANG nodes (hash values).
I am sure lots of optimizations can be invented for the latter, but
similar things can be done for the first as well.
===== About "we can make the module identifier optional, and specify
it in a query parameter"
How can we make the module identifier optional and avoid
interoperability issues?
If we accept the introduction of a managed module identifier, I
recommend to make it mandatory.
Not make it optional from implementation point of view but from a
request specification point of view.
Greetings,
Peter
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
