[core] Your cool presentation on friday core meeting
peter van der Stok <stokcons@xs4all.nl> Wed, 18 November 2015 08:09 UTC
Return-Path: <stokcons@xs4all.nl>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394861A00A8 for <core@ietfa.amsl.com>; Wed, 18 Nov 2015 00:09:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7-AWpWpKp_O for <core@ietfa.amsl.com>; Wed, 18 Nov 2015 00:09:35 -0800 (PST)
Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1201D1A009C for <core@ietf.org>; Wed, 18 Nov 2015 00:09:34 -0800 (PST)
Received: from webmail.xs4all.nl ([194.109.20.212]) by smtp-cloud6.xs4all.net with ESMTP id iw9X1r00L4aYjWA01w9XXd; Wed, 18 Nov 2015 09:09:32 +0100
Received: from [2001:983:a264:1:4449:a38c:4f0f:5f7c] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 18 Nov 2015 09:09:31 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Wed, 18 Nov 2015 09:09:31 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Alexander Pelov <a@ackl.io>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
Message-ID: <82c7667140aeaa28efab31a778a26204@xs4all.nl>
X-Sender: stokcons@xs4all.nl (zVIVVpJxFWIsNTKeEKqSIa24phm5HRWH)
User-Agent: XS4ALL Webmail
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/UVEkafdMFfFeRtlBdcMh_yS8Ql0>
Cc: Core <core@ietf.org>
Subject: [core] Your cool presentation on friday core meeting
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Nov 2015 08:09:39 -0000
Hi Alexander, I like to react to your presentation of CoMI during the Friday CoRE meeting. That is necessary for me to understand the underlying factual discussion. Your statement “A hash clash 5 years down the road can break your network” needs some clarification. I interpret that, out of the blue, a hash clash can occur and lead to problems in the network. This is simply not true. A new hash clash may occur when modules are changed and recompiled in a server. At that moment and before the server is made operational hash clashes are detected and remedial actions can be taken. Your next statement “hashes are underspecified” also needs some clarification. I understood from you that the remark was motivated by the absence of a full-proof process defining the solution of hash clashes. Such a process is not necessary to assure inter-operability. Once solved, the server returns the unique rehashed values and there is no need to specify how the rehash values are reached. Nevertheless, the draft suggests that a tilde is prefixed to the YANG name, after which it is rehashed. There is a very small probability that the new hash clashes with another one. Actually, you said to be afraid that the hashing algorithm may continuously generate the same set of clashing values independent of the prefix. I have no idea if this is true, and do not propose to check it for murmur. I agree that for efficiency reasons the same rehash process should be followed in all servers such that all servers with the same set of module versions arrive at the same rehash values. An approach different from rehashing is to assign the lowest not assigned natural number to the clashing names in lexicographical order. That will generally mean that two colliding names get the values 1 and 2 assigned, and very rarely the values 3 and 4 may be used. Last I should like to make a remark about probabilities. The whole world around us is based on probabilities. For example, there is a finite probability that a fatal fault will occur in an airplane during one hour of flight. Or that during digital transmission bits are toggled without detection by the checksum. These probabilities are calculated and should be smaller than a given probability value. This is a well-established engineering practice. Therefore, the clash probabilities are calculated in appendix E of the CoMI draft. It shows that for the targeted hash size and number of names, the probability that more than one clash occurs is 10^-3 smaller than the probability of one clash. These are quite small values. By the way, by relying on identifier assignment, there is also a finite probability that the same identifier is allocated to names on different modules (a hidden clash), due to power failures, undetected transmission errors, or simply copying mistakes. I recommend that in the security section of the identifier assignment draft, it is discussed how modules are detected with an identifier that has been assigned without going through the registration process. Hope this will stimulate further discussion. Peter -- Peter van der Stok vanderstok consultancy mailto: consultancy@vanderstok.org
- [core] Your cool presentation on friday core meet… peter van der Stok
- Re: [core] Your cool presentation on friday core … Alexander Pelov
- Re: [core] Your cool presentation on friday core … peter van der Stok
- Re: [core] Your cool presentation on friday core … Alexander Pelov