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. 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? If so, what happens to existing entries if the allowed name pattern is changed? Or is the pattern cast into stone? - 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. /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/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
