Hi Italo, Using a prefix (which can also be configured by the user) for the system created objects to avoid name collisions seems reasonable to me. I wouldn't use a symbol (like #), but instead would suggest a prefix string like "sys-".
But I think that it is appropriate to solve this within the specific data model rather that requiring a system wide solution. Thanks, Rob > -----Original Message----- > From: Italo Busi <[email protected]> > Sent: 19 June 2019 13:51 > To: Rob Wilton (rwilton) <[email protected]>; Juergen Schoenwaelder > <[email protected]> > Cc: [email protected]; Tarek Saad <[email protected]>; Andy Bierman > <[email protected]>; [email protected] > Subject: RE: [Teas] [netmod] Key collision between configured and > ephemeral list entries > > Hi Rob, > > Thanks a lot for your comments > > Your interpretation makes a lot of sense in case of an "intentional" name > clash (e.g., when an entry is configured by the client in the <running> DS > to configure some intended behavior, like admin status, for an entry > injected by the system in the <operational> DS): in this case the same > name/key value is used to indicate that the two DS entries are referring > to the same entity > > My concern is how to avoid "unintentional" name clashes (e.g., between an > entry configured by the client in the <running> DS and another entry > injected by the system in the <operational> DS) because in this situation > the behavior described below is not desirable: the two DS entries are > actually referring to two different entities which by accident got > assigned the same name/key value > > Italo > > -----Original Message----- > From: Rob Wilton (rwilton) [mailto:[email protected]] > Sent: mercoledì 19 giugno 2019 11:07 > To: Italo Busi <[email protected]>; Juergen Schoenwaelder > <[email protected]> > Cc: [email protected]; Tarek Saad <[email protected]>; Andy Bierman > <[email protected]>; [email protected] > Subject: RE: [Teas] [netmod] Key collision between configured and > ephemeral list entries > > Hi Italo, > > My interpretation of the NMDA guidelines are thus: > > - If multiple clients are writing the same values to <running> then the > clients must coordinate between themselves to ensure that the correct > values are written to <running>, otherwise the last verified change > written to <running> wins. Locks can be used to coordinate client writes > to <running> if required. > > - If multiple clients are writing to different datastores, e.g. one client > is writing to <running> and another is writing to some form of ephemeral > datastore, then the ephemeral datastore definition must specify what > mechanism is used to resolve configuration conflicts between configuration > datastores. Naively, my starting point would be to say that configuration > in an ephemeral datastore should override configuration that is in > <running>. > > - If the decision is from a data node configured in <running> and a data > node injected by the system into <operational> then it is up to the device > to decide how to resolve these (i.e. the system chooses which version of > the data node to use, and the result of that decision is tagged in > <operational> using the origin metadata). Generally, I would expect an > explicitly configured data node in <running> should take precedence over > system generated config, but there might be cases where this doesn't make > sense, and perhaps there might be cases where the data model recommends > different behaviour. > > - I would assume that there is only a single <operational> datastore. I'm > not sure whether NMDA explicitly requires this, but we couldn't think of > any scenario where multiple operational datastores would be helpful. > > Thanks, > Rob > > > > -----Original Message----- > > From: Teas <[email protected]> On Behalf Of Italo Busi > > Sent: 18 June 2019 18:24 > > To: Juergen Schoenwaelder <[email protected]> > > Cc: [email protected]; Tarek Saad <[email protected]>; Andy Bierman > > <[email protected]>; [email protected] > > Subject: 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:[email protected]] > > Sent: martedì 11 giugno 2019 20:37 > > To: Italo Busi <[email protected]> > > Cc: Andy Bierman <[email protected]>; [email protected]; Tarek Saad > > <[email protected]>; [email protected] > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/teas _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
