[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