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
