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" _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
