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"
]
}
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}
}
}
=== 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)
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.
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
-----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
