Hi Carl, I understand your concern, but isn't it up to the server to decide the response it provides in that case? Already I think the server needs to scatter/gather responses from the operational components in the system and stitch together a result. In this case, the stitching may fail and hence it reports an error of some sort (e.g., not-completely-applied) - what do you think?
Kent On 10/15/15, 9:05 AM, "Carl Moberg (camoberg)" <camob...@cisco.com> wrote: > > Maybe we¹re coming down to a definition of ³requirement² here. But the >issue I raised can be summarized as follows: > >³²² >The assumption of a 1:1 mapping ignores situations where a change to an >intended configuration leaf value may result in several instances of >applied configuration leaf values (operational state) to be updated in >the backend framework across several subsystems. >³²" > > My issue is that the requirement seems to ignore the situations and my >suggestion is to relax the requirement. > > I don¹t believe 1.C addresses the actual concern with the requirement. > >> On Oct 14, 2015, at 8:14 PM, Kent Watsen <kwat...@juniper.net> wrote: >> >> >> I believe that you are correct, it seems that we've doubled-down on 1C >>and so #5 should now be marked as DEAD. >> >> This action will be taken if no objection is made before tomorrow's >>interim. >> >> Thanks, >> Kent >> >> >> From: Robert Wilton <rwil...@cisco.com> >> Date: Tuesday, October 13, 2015 at 9:29 AM >> To: Kent Watsen <kwat...@juniper.net>, "netmod@ietf.org" >><netmod@ietf.org> >> Subject: Re: [netmod] opstate-reqs #5: Support for situations when >>structure of intended configuration is not the same as applied >> >> From the interim meeting two weeks ago, it was clarified that the >>schema of the intended configuration nodes are expected to be the same >>as the schema of the applied configuration nodes so that clients can >>easily relate between the two. >> >> I think that the requirement text for 1.C and the proposed updated text >>for 1.D makes this reasonable clear. >> >> Hence, is issue 5 now at the state where is can be closed as not being >>a requirement? Or is there something further that needs to be discussed >>first? >> >> Thanks, >> Rob >> >> >> On 30/09/2015 16:44, Kent Watsen wrote: >>> >>> It's time to tackle another issue, just before tomorrow's meeting, and >>>this time I'm picking a hard one: >>> >>> https://github.com/netmod-wg/opstate-reqs/issues/5 >>> >>> Already Carl, Mahesh, Einar, and Andy have posted 18 comments on the >>>GitHub issue tracker. Please first read the comments posted there >>>and then continue the discussion here on the mailing list (not on the >>>GitHub issue tracker). >>> >>> Note that this issue is closely tied to the definition of "applied >>>configuration", which is exactly what issue #4 regards >>>(https://github.com/netmod-wg/opstate-reqs/issues/4), for which Mahesh >>>and Einar have posted comments on already. As these two issues (#4 >>>and #5) are so highly related, I'm going to simultaneously open the >>>other issue for discussion now as well. >>> >>> Thanks, >>> Kent >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> >>> netmod@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
