Hi Alexander,
Thanks for your comments; it is nice to see a growing interest in CoMI.
I like to go back to the start of this thread, as you formulate it
below.
Thanks for the typo.
If I understand correctly, you want the server to point to URI where
possible hash clash information of even hash optimization is stored at a
server.
Personally, I don't mind that the /mg/yang.hash resource is used for
that.
The syntax of the file contents will become more complex than it is now.
Good news: it needs to be changed anyway, given the hash clash solution
discussion with 6tisch people.
Contents and syntax (JSON format?) of the file may turn out to be a
subject without limits.
For the moment I like to write down a new version 7 of the CoMI draft
containing the rehash approach for hash clashes discussed with 6tisch
and described in this thread by Andy.
I propose to continue the file contents discussion independent of the
current clash rehash solution.
Greetings,
Peter
Alexander Pelov schreef op 2015-06-03 17:00:
Hello everyone,
I would like to discuss with you to ideas/proposals in this mail,
namely:
1) Caching the yang clash file on a remote server
2) Compressing the URL representation of YANG hashes
1) Caching the yang clash file on a remote server
Even though hash collisions should happen rarely (if ever), there may
be cases when it could be inevitable, and as such, it may be
interesting to cache the clash_file somewhere on a remote server to
avoid sending it over the constrained wireless interface. It could be
used for other cases, where some frequently used resources are
re-hashed for performance purposes. Maybe it would be interesting to
allow the server to specify a remote location for the clash file? For
static collisions or optimizations it could be that the YANG
definition includes alternative hash values, which could be used in
addition to the normal ones.
2) Compressing the URL representation of YANG hashes
Another point (which is unrelated), is to elide the leading "A"s from
the base64 representation of the hash in the URL (which corresponds to
eliding the leading zeroes from the hash). As specified in section
5.4. a hash value of 0x0000007e will be encoded as AAAA_, but if the
leading A’s are elided it will be simply _
This could pose problems only if in the future the size of the hash
values is increased from 30 bits to some other (higher) value.
This, however, could be very useful when having to frequently access
the same resource. In such case, the server/network operator may
decide to re-hash the URI to a shorter version, e.g. the
/sys:system-state/sys:clock/sys:current-datetime could be remapped
from 0x15370408 and VNwQI to 0x1 and _
Best,
Alex
PS.
A typo (?), which may be already corrected, in the example of mod.uri
on Page 26: the two responses have different scheme "mod.uri" and
"moduri"
_______________________________________________
core mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
