Andy Bierman <[email protected]> wrote: > On Thu, Sep 28, 2017 at 9:28 AM, Robert Wilton <[email protected]> wrote: > > > Hi, > > > > Regarding the issue "Is it allowed to violate uniqueness of key values?", > > https://github.com/netmod-wg/datastore-dt/issues/10 > > > > We have discussed this further, and would like to extend the text in the > > draft to explicitly allow key uniqueness to be violated! > > > > > so we can rubber-stamp buggy servers?
One scenario is if you a have large ordered-by user list in <operational>, and the server starts to send the entries to a client. Before sending the last entry, the list might change, for example the first entry might have been moved to be last. Now the server might actually send the same entry twice. Another sceanrio is that the server sends a leafref that points to some node that hasn't been sent yet, but before the server gets to that node, it is removed. > I do not agree this is needed. > > > > > We have thought of several cases where it is possible that duplicate > > entries could appear, and we don't want to force any overhead on the device > > to guarantee that this does not occur, nor do we want to force > > synchronization between configuration processing and what is reported in > > <operational>. Of course, in normal circumstances this constraint, like > > the others, should not be violated. This is already stated in the draft. > > > > Examples of where uniqueness of list keys could be violated include: > > 1) If a device is internally paging the results back for a long list, then > > it is possible that a entry could have been reported near the beginning of > > the list, then moved, and then reported again at the end of the list. > > > > > The data is question is simply part of an <rpc-reply> and it is subject to > the validation > requirements for RPC replies only. Do you mean that the validation requirement applies to a pure snapshot of <operational>, but <get-data> is not required to return a pure snapshot, which means that the <get-data> reply can be invalid? /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
