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. 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: 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
