On Tue, May 19, 2015 at 8:47 AM, Michel Veillette <[email protected]> wrote: > Hi Andy > > No, I didn’t try to investigate if YANG hash clashes within existing modules > exist. > Multiple of them of proprietary and doing an extensive search is not > practical. > > The point is not to determine if such clashes exist but how the protocol will > handle them if they do exist. > The current answer seem to be bad luck, try again, your module can't be > implemented using CoMI. >
It is difficult to believe that a 6TISCH CoMI device is too small to store 16K of strings, but it will be powerful enough to run YANG modules intended for NETCONF devices such as routers. There is a very small chance that a module in progress has hash collisions in it, and the name of a node has to be changed to fix it (before the module is published). IMO this is the least painful solution. > Michel Veillette Andy > 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: 19 mai 2015 11:35 > To: Michel Veillette > Cc: [email protected]; [email protected]; Core > Subject: Re: [core] CoMI rehashing > > On Tue, May 19, 2015 at 8:23 AM, Michel Veillette > <[email protected]> wrote: >> Hi Peter >> >> Your propose solution doesn't seem to address YANG hash clashes happening >> within a YANG module. >> >> Multiple times in your document, you assume that clashes can't happen within >> a YANG module. >> Page 1, "It is assumed that no clashes occur within one module, and by >> prefixing a module identifier to the hash, clashing hashes can be >> distinguished" >> Page 3, "A data node is completely identified by the module identifier and >> the hash value." >> >> We can probaly make this assumption for YANG modules specifically design for >> CoMI but this is not true for existing YANG modules and future modules not >> designed with CoMI in mind. >> > > > Dos this mean you have identified existing YANG modules that would have > multiple nodes with the same hash value? > I have not found any so far. > > IMO it is much more reasonable to make sure that a YANG module intended for > use in CoMI does not have any clashes. > > >> ======= >> >> About "the client creates a "server_table" with entries: <server id, old >> hash, M_id, new hash> " >> >> Let say we have the following two data nodes: >> /sys:system-state/sys:clock/sys:current-datetime, 355927048 >> /sys:system-state/sys:clock/sys:boot-datetime, 355927048 >> > > But these are the wrong hash values. > >> Having the following table within the client is not sufficient to >> distinguate between the "current-datetime" and the "boot-datetime". >> fe80::200:f8ff:fe21:67cf, 355927048, ietf-system, 783481403 >> fe80::200:f8ff:fe21:67cf, 355927048, ietf-system, 530731873 >> > > The assumption is that modules for CoMI will be checked for hash collisions, > and the module will be altered to remove any collisions. Since a module has > about 100 nodes in it and it takes about 70,000 nodes for a 50% chance at a > collision, it will be quite easy to prevent clashes in a single module. > > > > Andy > >> ======== >> >> Introducing the concept of "hash clash" error help to avoid the need to >> retreive the "clash_file" when no clashes exist. >> However, if we agree that clashes may exist within a YANG module, we are >> back to square one with the original rehashing mechanism. >> >> Michel Veillette >> System Architecture Director >> Trilliant Inc. >> Tel: 450-375-0556 ext. 237 >> [email protected] >> www.trilliantinc.com >> >> -----Original Message----- >> From: peter van der Stok [mailto:[email protected]] >> Sent: 19 mai 2015 03:23 >> To: Michel Veillette >> Cc: Core; [email protected] >> Subject: CoMI rehashing >> >> Hi Michel, >> >> Apologies for reacting so late, but we had many discussions which slowly >> converged to the solution described in the attachment. >> >> WE aim at rehashing when a clash occurs. >> The client only needs minimal storage space: table with the names of the >> modules. >> Per rehash collision, the client only stores old hash, new hash, and >> module identifier >> >> We think that a global module numbering of all relevant modules, >> administrated by IANA, is a large undertaking. >> Given the struggle we see elsewhere to save bytes, we think also that we >> should minimize the payload. >> >> Greetings, >> >> Peter >> >> -- >> Peter van der Stok >> vanderstok consultancy >> mailto: [email protected] >> www: www.vanderstok.org >> tel NL: +31(0)492474673 F: +33(0)966015248 >> >> _______________________________________________ >> core mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/core _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
