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

Italo Busi <> Tue, 11 June 2019 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B5F92120133; Tue, 11 Jun 2019 10:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YBICJltCyK0A; Tue, 11 Jun 2019 10:43:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC78F12012A; Tue, 11 Jun 2019 10:43:34 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 6825BED906C18F394E62; Tue, 11 Jun 2019 18:43:32 +0100 (IST)
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Tue, 11 Jun 2019 18:43:27 +0100
From: Italo Busi <>
To: Juergen Schoenwaelder <>
CC: Andy Bierman <>, "" <>, Tarek Saad <>, "" <>
Thread-Topic: [netmod] [Teas] Key collision between configured and ephemeral list entries
Thread-Index: AQHVIGv3uNMq5vuvr0+PtfoTsE5mlKaWijaAgAAB7wCAABg74P///YkAgAASdtA=
Date: Tue, 11 Jun 2019 17:43:27 +0000
Message-ID: <91E3A1BD737FDF4FA14118387FF6766B2775D16D@lhreml504-mbs>
References: <91E3A1BD737FDF4FA14118387FF6766B2774DF6C@lhreml504-mbs> <062401d5160d$a568ea80$> <> <> <91E3A1BD737FDF4FA14118387FF6766B2774E51F@lhreml504-mbs> <028b01d51933$1015fa80$> <91E3A1BD737FDF4FA14118387FF6766B2775CF49@lhreml504-mbs> <> <> <91E3A1BD737FDF4FA14118387FF6766B2775D052@lhreml504-mbs> <>
In-Reply-To: <>
Accept-Language: it-IT, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_91E3A1BD737FDF4FA14118387FF6766B2775D16Dlhreml504mbs_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netmod] [Teas] Key collision between configured and ephemeral list entries
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Jun 2019 17:43:38 -0000

Hi Juergen,

Thanks for your reply: see some comments of mine in line below


-----Original Message-----
From: Juergen Schoenwaelder []
Sent: martedì 11 giugno 2019 19:19
To: Italo Busi <>
Cc: Andy Bierman <>;; Tarek Saad <>;
Subject: Re: [netmod] [Teas] Key collision between configured and ephemeral list entries

On Tue, Jun 11, 2019 at 04:36:08PM +0000, Italo Busi wrote:
> I agree with your statements as long as we consider two sources for
> the same information/instance. In this case, my understanding is that
> the same key value is intentionally assigned by the two sources to
> indicate that they are representing the same information/instance and
> only one instance needs to be applied within the operational DS
> The issue we are trying to solve is slightly different. We have two different instances from different sources and both of them need to be applied within the operational DS, but unfortunately they have got assigned the same key value ...

It does not really matter whether the name clash is intentional or not. Only one can be used and it should be clear which one will be the winner.
[Italo Busi] I agree. This is why I think we need to avoid unintentional name clash.

I do understand that you want to design the models so that name clashes can be avoided and this is likely fine for what you need but you need to think through all cases.

- Will names not matching the pattern be rejected?
[Italo Busi] Good question. I think that the client should be allowed to create entries with intentional name clashes

If so, what happens
  to existing entries if the allowed name pattern is changed? Or is
  the pattern cast into stone?
[Italo Busi] Another good question. My feeling is that the solution would be much simpler if the prefix is decided by the server, communicated to the client and never changed.

- Another option, in principle, is to suggest that names are chosen
  such that they have a low probability to collide. This sometimes
  leads to simpler implementations since clients do not have to
  generate names conforming to some (configurable?) patterns and
  instead create a name with low collision probability and if the
  config does not make it into <operational>, the client handles the
  name clash. Note that some clients may want to tag their entries
  with specific IDs anyway so that they can easily recognize their
  entries, i.e., clients may have other good reasons to avoid
  generating names that have a high probability to clash.
[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


Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <>