Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
Hi - >From: "Einar Nilsen-Nygaard (einarnn)" >Sent: Oct 20, 2015 5:17 AM >To: Martin Bjorklund >Cc: "netmod@ietf.org" >Subject: Re: [netmod] opstate-reqs #5: Support for situations when structure >of intended configuration is not the same as applied ... >To perhaps be a little more precise, I mean that it is the >server's job to make the information about whether or not >intended config has been instantiated correctly in a way >that is really easy to correlate with the intended config >asserted by the client. In terms of aggregating the status >of the operational leaves into a ingle value that could, >for example, be diff'd with the intended config, that would >meet the criteria of being easy to correlate with the intended >config. This discussion seems to conflate three distinct problems. One, which is a classic configuration management problem and which was one of the operator requirements going into this work from the beginning, is the ability to compare two configurations. A special case of this is comparing a system's actual configuration with an intended configuration. Should be incredibly straightforward. The second problem, which was mentioned more-or-less in passing at the IAB workshop, is in the realm of intention-based management. One of the tools needed to implemented intention-based management is the ability to compare a systems actual *operational* state with an intended operational state. The similarity between these two problems is superficial; even with a deep understanding of the relationship between the two state spaces (including acknowledgement of the fact that operational state often depends on factors that are outside the configuration) it can be very difficult to get from A to B. The third problem arises from excessive complications in the inter- relationships between model components, resulting in situations where one can't fully validate a request without actually trying to activate it. This largely avoidable problem is a question of both system and management interface design. In legacy environments, however, it may be intractable. >What we may find is that thinking about requirements like this may >make us more mindful of how we define the relationship between >intended config and how our internal components work together >to achieve it and how we expose the success or failure of config >operations in a way that is easier for users to make sense of. Another way of putting it: It *is* possible to design management interfaces in such a way as to make both kinds of interactions easier. However, as long as the working assumption is that these technologies will essentially serve as a wrapper for legacy CLIs, making this work will require vast amounts of duct tape. >Additionally, I'm not saying that there isn't operational state >that each of the N internal components have. That still exists, >and will continue to exist as part of ongoing operational management. Agreed. But there's going to be tension between supporting what one might need to handle a modular system designed from the outset to be managed using this technology, and supporting the crufty realities of systems where the management interface has been cobbled together over many years with short-term expediency as its guiding principle. Randy ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
> On Oct 20, 2015, at 12:48 PM, Martin Bjorklund wrote: > > "Einar Nilsen-Nygaard (einarnn)" wrote: >> Carl, >> >> A bit of a late response, sorry, but was on vacation. Please see >> inline. >> >>> On Oct 15, 2015, at 2:53 PM, Robert Wilton -X (rwilton - ENSOFT >>> LIMITED at Cisco) wrote: >>> >>> Hi Carl, >>> >>> On 15/10/2015 14:05, Carl Moberg (camoberg) 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. >>>> “”" >> >> The operational state you are taking about here is not, per my >> understanding of "applied configuration" what is meant by applied >> configuration. The "several instances" are instead implementation >> detail that are perhaps changed as a result of changing a single >> intended configuration leaf. >> >> And at this point I agree with Rob and will say that, from an end >> user's perspective, it is not reasonable to expect them to patch >> together the 1:N relationship between intended config and what I will >> call "operational state" (NOT applied configuration) to determine if >> the device is actually doing what it was asked to do. The fact that >> this is exactly what we have typically asked users to do is, I >> believe, one of the key reasons why we are seeing requirements >> articulated this way. > > Ok. Do you mean that instead you want the server to do this job? > I.e., if it happens to distribute a single leaf in N internal > components, it should aggregate the status of the leaf's value in > these N internal components into one single value, and report that > value? To perhaps be a little more precise, I mean that it is the server's job to make the information about whether or not intended config has been instantiated correctly in a way that is really easy to correlate with the intended config asserted by the client. In terms of aggregating the status of the operational leaves into a ingle value that could, for example, be diff'd with the intended config, that would meet the criteria of being easy to correlate with the intended config. What we may find is that thinking about requirements like this may make us more mindful of how we define the relationship between intended config and how our internal components work together to achieve it and how we expose the success or failure of config operations in a way that is easier for users to make sense of. Additionally, I'm not saying that there isn't operational state that each of the N internal components have. That still exists, and will continue to exist as part of ongoing operational management. Cheers, Einar > /martin > > > > >> >>>> My issue is that the requirement seems to ignore the situations and my >>>> suggestion is to relax the requirement. >>> I think that the operator requirement is stating that the multiple >>> actual applied configuration leaves across multiple subsystems need to >>> be mapped back to a single logical leaf for the purposes of the >>> applied config leaf that is exposed to the operators. >>> >>> If no such mapping is possible then this would imply that there is no >>> way that the operator can determine whether a particular item of >>> configuration is actually in effect on a system. Is this reasonable >>> behaviour for a system? >>> >>> If such a mapping is possible, then I can see benefit in performing >>> such a mapping on the device itself rather than requiring each and >>> every operator to know and program the mapping. >> >> +1 >> >> Cheers, >> >> Einar >> >> >>> Is the main concern here that the cost of implementing this mapping in >>> the system may be prohibitively expensive? >>> >>> Thanks, >>> Rob >>> >>>> >>>> I don’t believe 1.C addresses the actual concern with the requirement. >>>> >>>>> On Oct 14, 2015, at 8:14 PM, Kent Watsen wrote: >>>>> >>>>> >>>>> I believe that you are correct, it seems that we've doubled-down on 1C >
Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
"Einar Nilsen-Nygaard (einarnn)" wrote: > Carl, > > A bit of a late response, sorry, but was on vacation. Please see > inline. > > > On Oct 15, 2015, at 2:53 PM, Robert Wilton -X (rwilton - ENSOFT > > LIMITED at Cisco) wrote: > > > > Hi Carl, > > > > On 15/10/2015 14:05, Carl Moberg (camoberg) 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. > >> “”" > > The operational state you are taking about here is not, per my > understanding of "applied configuration" what is meant by applied > configuration. The "several instances" are instead implementation > detail that are perhaps changed as a result of changing a single > intended configuration leaf. > > And at this point I agree with Rob and will say that, from an end > user's perspective, it is not reasonable to expect them to patch > together the 1:N relationship between intended config and what I will > call "operational state" (NOT applied configuration) to determine if > the device is actually doing what it was asked to do. The fact that > this is exactly what we have typically asked users to do is, I > believe, one of the key reasons why we are seeing requirements > articulated this way. Ok. Do you mean that instead you want the server to do this job? I.e., if it happens to distribute a single leaf in N internal components, it should aggregate the status of the leaf's value in these N internal components into one single value, and report that value? /martin > > >> My issue is that the requirement seems to ignore the situations and my > >> suggestion is to relax the requirement. > > I think that the operator requirement is stating that the multiple > > actual applied configuration leaves across multiple subsystems need to > > be mapped back to a single logical leaf for the purposes of the > > applied config leaf that is exposed to the operators. > > > > If no such mapping is possible then this would imply that there is no > > way that the operator can determine whether a particular item of > > configuration is actually in effect on a system. Is this reasonable > > behaviour for a system? > > > > If such a mapping is possible, then I can see benefit in performing > > such a mapping on the device itself rather than requiring each and > > every operator to know and program the mapping. > > +1 > > Cheers, > > Einar > > > > Is the main concern here that the cost of implementing this mapping in > > the system may be prohibitively expensive? > > > > Thanks, > > Rob > > > >> > >> I don’t believe 1.C addresses the actual concern with the requirement. > >> > >>> On Oct 14, 2015, at 8:14 PM, Kent Watsen 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 > >>> Date: Tuesday, October 13, 2015 at 9:29 AM > >>> To: Kent Watsen , "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, > >&g
Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
Carl, A bit of a late response, sorry, but was on vacation. Please see inline. > On Oct 15, 2015, at 2:53 PM, Robert Wilton -X (rwilton - ENSOFT LIMITED at > Cisco) wrote: > > Hi Carl, > > On 15/10/2015 14:05, Carl Moberg (camoberg) 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. >> “”" The operational state you are taking about here is not, per my understanding of "applied configuration" what is meant by applied configuration. The "several instances" are instead implementation detail that are perhaps changed as a result of changing a single intended configuration leaf. And at this point I agree with Rob and will say that, from an end user's perspective, it is not reasonable to expect them to patch together the 1:N relationship between intended config and what I will call "operational state" (NOT applied configuration) to determine if the device is actually doing what it was asked to do. The fact that this is exactly what we have typically asked users to do is, I believe, one of the key reasons why we are seeing requirements articulated this way. >> My issue is that the requirement seems to ignore the situations and my >> suggestion is to relax the requirement. > I think that the operator requirement is stating that the multiple actual > applied configuration leaves across multiple subsystems need to be mapped > back to a single logical leaf for the purposes of the applied config leaf > that is exposed to the operators. > > If no such mapping is possible then this would imply that there is no way > that the operator can determine whether a particular item of configuration is > actually in effect on a system. Is this reasonable behaviour for a system? > > If such a mapping is possible, then I can see benefit in performing such a > mapping on the device itself rather than requiring each and every operator to > know and program the mapping. +1 Cheers, Einar > Is the main concern here that the cost of implementing this mapping in the > system may be prohibitively expensive? > > Thanks, > Rob > >> >> I don’t believe 1.C addresses the actual concern with the requirement. >> >>> On Oct 14, 2015, at 8:14 PM, Kent Watsen 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 >>> Date: Tuesday, October 13, 2015 at 9:29 AM >>> To: Kent Watsen , "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 >>>
Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
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)" 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 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 >> Date: Tuesday, October 13, 2015 at 9:29 AM >> To: Kent Watsen , "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
Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
Hi Carl, On 15/10/2015 14:05, Carl Moberg (camoberg) 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 think that the operator requirement is stating that the multiple actual applied configuration leaves across multiple subsystems need to be mapped back to a single logical leaf for the purposes of the applied config leaf that is exposed to the operators. If no such mapping is possible then this would imply that there is no way that the operator can determine whether a particular item of configuration is actually in effect on a system. Is this reasonable behaviour for a system? If such a mapping is possible, then I can see benefit in performing such a mapping on the device itself rather than requiring each and every operator to know and program the mapping. Is the main concern here that the cost of implementing this mapping in the system may be prohibitively expensive? Thanks, Rob I don’t believe 1.C addresses the actual concern with the requirement. On Oct 14, 2015, at 8:14 PM, Kent Watsen 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 Date: Tuesday, October 13, 2015 at 9:29 AM To: Kent Watsen , "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
Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
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 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 > Date: Tuesday, October 13, 2015 at 9:29 AM > To: Kent Watsen , "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
Re: [netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
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 mailto:rwil...@cisco.com>> Date: Tuesday, October 13, 2015 at 9:29 AM To: Kent Watsen mailto:kwat...@juniper.net>>, "netmod@ietf.org<mailto:netmod@ietf.org>" mailto: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>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.org<mailto:netmod@ietf.org>https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
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.org https://www.ietf.org/mailman/listinfo/netmod ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] opstate-reqs #5: Support for situations when structure of intended configuration is not the same as applied
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.org https://www.ietf.org/mailman/listinfo/netmod
