Hi Michel,
When clashes can exist within a module, indeed the intended data node
cannot be determined from the hash value and the module name.
We all agree about that.
If a clash happens within a module, the original data node names need to
be stored in the client.
The new hash value can be found by inspecting the clash-file.
In conclusion:
(1) when no clashes occur within a module it is sufficient to store the
module name and information per clash per server in the client.
(2) When clashes occur in a module, also the names of the clashing data
nodes need to be stored in the client.
(3) When no clashes at all occur, no storage space is needed in the
client.
Condition (1) produces acceptable overhead IMO.
condition (2) should be avoided but can be handled by the protocol
condition (3) may well be the norm in most cases.
Peter
Michel Veillette schreef op 2015-05-19 17:23:
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.
=======
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
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
========
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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
