Hi Andy, > Le 3 juin 2015 à 23:37, Andy Bierman <[email protected]> a écrit : > > On Wed, Jun 3, 2015 at 12:48 PM, Michel Veillette > <[email protected]> wrote: >> About "I would prefer if hash collisions in a single module were not >> allowed." >> Agreed but how this is implemented. >> > > > By checking the YANG hashes before it is published, > similar to checking the YANG syntax with a YANG compiler.
> > >> About "But these numbers do not exist in any modules and so they cannot be >> relied on in CoMI. >> I understand but I assume that a module can be re-published with the added >> statement when require. If a CoMI implementer try to implement a module >> containing a clash, he can look for a version of this module containing the >> special YANG statement. The likelihood of such clash is extremely low and >> such fallback solution won’t be required often. However, the RFC will >> specify how to resolve such situation if this ever happen. This statement >> can also be used to address the need for data node identifier compactness as >> mentioned by Alexander in its original email. >> > > I think the ad-hoc id assignments are pointless because they are not > universal. The only thing that can be counted on is the module name > and the XPath absolute path expression of each object. Having a way of re-mapping (or aliasing) an ID to a locally-understood/negotiated ID is really important in some networks where the radio resources are extremely limited. If you are able to use IDs 1-23 and you have URL hash compression, you save 8 bytes (using standard CBOR, no changes here whatsoever). For IDs 24-63 you save 7 bytes, 63-255 - 6 bytes (without doing any particular treatment). When using a general hash function, the probability of getting a hash value < 255 is 10E-7, and choosing an URI that statically gives you such ID simply sounds wrong (and unrealistic). Two options are then possible here: 1) Leave this out of CoMI 2) Have a minor accommodation, and require no additional resources on the devices Both require defining hash clash handling mechanism, so here the entire discussion on how to handle this is pertinent. For me, 2) can be implemented in two ways: 2.a) Explicit ID re-mapping (or aliasing) through a (external) file. Here, it would be nice to have a way to specify the URI of the file, e.g. on the server or on a remote location. Something like the mod.uri . 2.b) Explicit ID re-mapping (or aliasing) in the YANG module (e.g. through the "id" option mentioned by Michel or maybe with an extension, e.g. comi:id) Note that if this is considered hash aliasing (we forget the re-mapping), then the behavior can be very simple, e.g.: It is up to the implementer to define the hash aliases, if any. In case of clash with a YANG hash value, the alias must be ignored. In case of clash with another alias, both aliases are ignored. ======================= CoMI can decide on a small concession for aliasing uses - say that YANG string hash values MUST be >= 64 (256?). The compiler can check that all hashes fulfill this before publishing. This way, there is even NO need to add any statement about alias clashes. It would be up to the implementer to chose the appropriate way of aliasing (if any). Aliases would be local in scope. What do you think about it? ======================= Best, Alexander > > >> About "In NETCONF, modules tend to use augment a lot" >> In my document " draft-vanderstok-core-comi-06 - MV.docx ", I propose a new >> definition to address this. >> > > What is it? > IMO you should post comments to the mailing list not markup > to a word document. It is too hard to follow. > > >> Module Context: A module context is composed of all data nodes, >> notifications and RPCs defined in a YANG module and included sub-modules or >> added to them using the augment YANG statement. >> > > Almost -- this is defined in RFC 6020 -- the augmenting nodes are > not part of the augmented module. They will be returned in > NETCONF and RESTCONF retrieval operations for an ancestor node > but they are not part of the augmented module. Only objects > defined in the module namespace are part of the module. > > > Andy > > > >> Section 4.1.3.4 show an example of include, import and augment. >> >> 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 14:54 >> 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 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
