On Wed, Jun 3, 2015 at 11:16 AM, Michel Veillette
<[email protected]> wrote:
> Hi Andy
>
> Couple of questions about your proposed solution.
>
> === Question #1, New YANG statement
>
> Your solution works only if hash clashes within a module are resolved at
> design time. If not, the error message will return the following information
> which is not sufficient to resolve which data node is which.
>
> { "1234": [
> "module-A":"4567",
> "module-A":"6523"
> ]
> }
>
The original proposal had a 3-tuple { module-name, path-expr, new-hash }
We discussed some optimizations in the 6TISCH call to reduce the size of
the path-expr and still not require the client to store all the path strings,
such as store a few bytes from the path strings like 6th and 11th bytes
(Avoid the common ietf- prefix for many module names).
This is not deterministic. Only the full path string is fool-proof.
I would prefer if hash collisions in a single module were not allowed.
They need to be resolved at design time. If this is not possible, then
a standard rehash algorithm should be used so the collision is resolved
in a predictable way. e.g., try appending "_", then try "__", etc.
The result would be that hash collisions in a single module do not
occur in CoMI.
> Is it possible/acceptable to request a new YANG statement to manually assign
> a ID to a data node?
> Same question for a module ID?
>
> For example (see "id 16" and "id 25" bellow) :
>
> module a {
> namespace a-ns;
> prefix a;
> id 16;
> revision 2015-01-01;
>
> leaf leafA1 { type string; id 25 }
> container containerA {
> leaf leafA2 { type string}
> }
> }
You could have an extension statement do anything you want:
comi:id 16;
But these numbers do not exist any any modules and so they
cannot be relied on in CoMI.
>
> === Question #2, Introduction of an optional query parameter used to target a
> specific module
>
> For nodes / networks which can afford a slitely larger payload (IEEE
> 802.15.4g for example) but want to avoid the processing and storage
> associated with the porposed error message, are you opposed to the support of
> an optional CoAP query parameter use carry the module name or module ID ?
>
> For example:
>
> GET example.com/Y8d7s?select= ietf-6tisch-mac
>
> === Question #3, Use of the select query parameter instead of the URI
>
> Are you oposed to the use of the select query parameter instead of the URI to
> identify data node(s)
>
Not really.
I don't know how mixed the modules will get in CoMI.
In NETCONF, modules tend to use augment a lot,
so the nodes from 'module-A' may be nested nodes.
Retrieving just the augmenting nodes and ignoring the
augmented nodes would likely be operationally useless.
e.g., when augmenting a list, the key leafs are needed
to identify the instance.
I would like to keep CoMI extremely simple.
More bells and whistles means increased
memory and CPU requirements. I am glad CORE and 6TISCH
WGs are so concerned about constrained resources.
Only the most important bells and whistles will get standardized.
> For example:
>
> GET example.com/mg?select=Y8d7s
> GET example.com/mg?select=Y8d7s,NKHaA
> GET example.com/mg?select=ietf-6tisch-mac(Y8d7s,NKHaA)
>
> === Question #4, Compressing YANG hash base64 representation
>
> Are you oposed to the compression of the base64 representation as propsed by
> Alexander.
>
No. Optimizations that reduce the encoding size are important.
I want to use standard CBOR. No special hacks just for CoMI.
> For example:
>
> GET example.com/mg?select=7s
> Instead of
> GET example.com/mg?select= AAA7s
>
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> [email protected]
> www.trilliantinc.com
>
>
Andy
> -----Original Message-----
> From: Andy Bierman [mailto:[email protected]]
> Sent: 3 juin 2015 13:09
> To: Michel Veillette
> Cc: Alexander Pelov; [email protected]; [email protected]
> Subject: Re: [core] CoMI remote server clash file and YANG hash in URL
>
> On Wed, Jun 3, 2015 at 9:05 AM, Michel Veillette
> <[email protected]> wrote:
>> Hi Alexander
>>
>> At the last 6TiSCH bi-weekly call, 4 solutions have been presented to the
>> hash clashes problem. Two based on a rehash table and two based on a new
>> CoAP query parameter carrying the module name or registered module ID. This
>> query parameter is used to select unambiguously the targeted data node(s)
>> assuming that any hash collision within a module have been resolved at
>> design time. You can find this presentation in attachment.
>>
>> Both of your proposals make sense to me but I still hope that the clash file
>> can be avoided or be optional.
>>
>
>
> I agree we should not need the client to retrieve the rehash info before
> using a server.
> The CoMI authors have discussed a solution which I will try to write up today
> where a special "hash-clash" error is returned by CoMI if a rehash is needed.
>
> 1) client requests module-A object with hash "1234";
> there is no extended-name/local-name,
> just the YANG hash, used in any request
>
> 2) if '1234' has a collision in this server then a special error code is
> returned;
> The return payload has the rehash info [old-hash, { module-name,
> new-hash }+]
> { "1234": [
> "module-A":"4567",
> "module-X":"6523"
> ]
> }
>
> 3) the client gets the error info, and knows which module its "1234" is
> from.
> It finds the correct module name in the array and replaces its
> old-hash
> with the new-hash.
>
> 4) client re-sends the request, using hash "4567" instead of "1234"
>
> The rehash table goes away, and only this error info is used instead.
>
>> Michel Veillette
>> System Architecture Director
>> Trilliant Inc.
>> Tel: 450-375-0556 ext. 237
>> [email protected]
>> www.trilliantinc.com
>>
>
>
> Andy
>
>>
>> -----Original Message-----
>> From: core [mailto:[email protected]] On Behalf Of Alexander Pelov
>> Sent: 3 juin 2015 11:01
>> To: [email protected]; [email protected]
>> Subject: [core] CoMI remote server clash file and YANG hash in URL
>>
>> 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
>>
>> _______________________________________________
>> core mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/core
>>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
