Re: [netmod] [Teas] Key collision between configured and ephemeral list entries

Italo Busi <Italo.Busi@huawei.com> Wed, 19 June 2019 11:51 UTC

Return-Path: <Italo.Busi@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D0112013C; Wed, 19 Jun 2019 04:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 icRnrLwAgFmU; Wed, 19 Jun 2019 04:51:22 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE615120071; Wed, 19 Jun 2019 04:51:21 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4369BB0A9876F14B0E19; Wed, 19 Jun 2019 12:51:19 +0100 (IST)
Received: from LHREML504-MBS.china.huawei.com ([10.201.109.59]) by LHREML713-CAH.china.huawei.com ([10.201.108.36]) with mapi id 14.03.0415.000; Wed, 19 Jun 2019 12:50:46 +0100
From: Italo Busi <Italo.Busi@huawei.com>
To: Qin Wu <bill.wu@huawei.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: "netmod@ietf.org" <netmod@ietf.org>, Tarek Saad <tsaad.net@gmail.com>, Andy Bierman <andy@yumaworks.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] [netmod] Key collision between configured and ephemeral list entries
Thread-Index: AdUmZqoTYM9FWD41TPSJAy7ckQz9KQALhvRQ
Date: Wed, 19 Jun 2019 11:50:45 +0000
Message-ID: <91E3A1BD737FDF4FA14118387FF6766B2776A7C8@lhreml504-mbs>
References: <B8F9A780D330094D99AF023C5877DABAA499B8FC@nkgeml513-mbx.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAA499B8FC@nkgeml513-mbx.china.huawei.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.246.126]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/o2h2_mbFz31iaYVbXwQ6K6Hfcgk>
Subject: Re: [netmod] [Teas] Key collision between configured and ephemeral list entries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2019 11:51:24 -0000

Hi Qin,

Thanks for your feedback

The <lock> operation would allow the two clients not to create any unintentional name clash. Therefore, I think, the issue of avoiding unintentional name clash applies only between <running> and <operational> DS

Italo

-----Original Message-----
From: Qin Wu 
Sent: mercoledì 19 giugno 2019 08:24
To: Italo Busi <Italo.Busi@huawei.com>;; Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>;
Cc: netmod@ietf.org; Tarek Saad <tsaad.net@gmail.com>;; Andy Bierman <andy@yumaworks.com>;; teas@ietf.org
Subject: RE: [Teas] [netmod] Key collision between configured and ephemeral list entries

Sorry to chime in.
If my understanding is correct, I think in most cases the DS should be shared by multiple clients. In the first case, the <lock> operation should be used to prevent two clients from writing the content into the same datastore at the same time.

-Qin
-----邮件原件-----
发件人: Teas [mailto:teas-bounces@ietf.org] 代表 Italo Busi
发送时间: 2019年6月19日 1:24
收件人: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>;
抄送: netmod@ietf.org; Tarek Saad <tsaad.net@gmail.com>;; Andy Bierman <andy@yumaworks.com>;; teas@ietf.org
主题: Re: [Teas] [netmod] Key collision between configured and ephemeral list entries

Hi Juergen,

What is the DS architecture you have in mind with multiple client creating entries?

Are the two clients creating entries in the same <running> DS or in two different <running> DS?

In the latter case, the two clients could also rely on different <operational> DS and therefore can assign the same name to different entries (since they will be instantiated in different DS). There is no need for them to avoid name clash

In the former case, a name clash would cause one client to override the configuration of another client

Are the two clients aware of each other?

I take the opportunity to clarify one point (not sure I have been clear about it). I do not think we need to define any rule which is enforced by the server to avoid name clashes since the server cannot understand whether the name clash is intentional or not. I think we just need to define some known/common/standard rules that allow the client(s) to avoid creating unintended name clashes.

Thanks, Italo

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: martedì 11 giugno 2019 20:37
To: Italo Busi <Italo.Busi@huawei.com>;
Cc: Andy Bierman <andy@yumaworks.com>;; teas@ietf.org; Tarek Saad <tsaad.net@gmail.com>;; netmod@ietf.org
Subject: Re: [netmod] [Teas] Key collision between configured and ephemeral list entries

On Tue, Jun 11, 2019 at 05:43:27PM +0000, Italo Busi wrote:

> [Italo Busi] If the client knows the prefix used by the server, it can 
> pick up a different prefix and use it to tag its own entries. I think 
> this rule is not really complex and it seems much simpler than 
> managing unintended name clashes

A prefix only helps a little. Once you have multiple clients creating entries, you will have to handle collisions again. Sometimes solving the more general case leads to solutions that also work nicely in simpler special cases.
	
/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas