On Thu, Sep 14, 2017 at 10:08 AM, Robert Wilton <rwil...@cisco.com> wrote:
> > > On 14/09/2017 16:35, Balazs Lengyel wrote: > > See below! > On 2017-09-14 16:32, Martin Bjorklund wrote: > > Hi Balazs, > > Thanks for your review. Comments inline. > > Balazs Lengyel <balazs.leng...@ericsson.com> <balazs.leng...@ericsson.com> > wrote: > > Hello, > > Reading the draft-ietf-netmod-revised-datastores-04 some comments: > > General) The system often adds data to the <running> or <intended> > datastore already not just to <operational>: e.g. > > UC1: I have a server configured in running. I need to bind it to an > ip-address. The ip-address might be the local loopback address, > however if that is only added to <operational>, validation will > fail indicating that the server is bound to a non-existent > address. How to handle this? > > UC2: I have a set of capabilities set by the system > e.g. supported-reporting-intervals. I need to configure a job that > MUST use one of these intervals. If the supported-reporting-intervals > are only added to <operational> I can not validate the > selected-interval in my configured job. > > My proposal is to allow the system to add data to running as > well. Actually I think that is a more relevant case then adding > configuration just to <operation>. > > I think the consensus is that in general it is a bad idea if servers > (spontaneously) add data to <running>. However, there is nothing in > the new or old architectures that prohibits this. > > BALAZS: I strongly disagree. I know others are also adding stuff to > running as well. > IMHO the above use cases are real and used and actually important for us. > I would like to see them included in some way. > > I basically agree with Martin here. > > The architecture is cleaner if <running> is only written by the client. > This avoid requiring clients tracking unexpected changes to running, and > opens up the possibility of validating configuration off the box. Ideally > extra stuff should be added into <intended> and then become visible in > <operational>. > > I understand that some systems add data to <running>, and this is fine. > But I think that it is better for an architecture document to be silent on > this point. > > I agree with Balazs that system-created nodes in running are quite common and the vendors doing it have no intention of changing it. If the added nodes need to be saved in non-volatile storage then then definitely belong in <running>. IMO the architecture is rather opaque wrt/ the interactions between datastores, especially the interactions between <running> and <intended>. Now it not only prunes inactive nodes, it adds system nodes? Maybe it is too early for NMDA to be making lots of rules about how YANG works with new (and unimplemented) datastores. Thanks, > Rob > > Andy > > > regards Balazs > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com > > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
