On Wed, Oct 14, 2015 at 11:00 AM, Kent Watsen <[email protected]> wrote:
> > Thank you Robert for bringing the discussion back to the github issues. > > Robert writes: > > > In particular: > > - does it include support for templating (as per > openconfig-netmod-opstate-01 section 7.3.)? > > - is it allowed to represent system created objects that have no > corresponding configuration? > > > > Requirement 1.D states > > D. For asynchronous systems, when fully synchronized, the data > in the applied configuration is the same as the data in the > intended configuration. > > > > > So, if this requirement statement stands as being valid (which I think > it should) then that would imply that the answer for both the two issues > above must be "no". The only question would be whether these need to be > explicitly listed out? > > [KENT] so I think I have to (begrudgingly) agree with your logic. I > have heard the operators state that they want the intended/applied > comparison to be drop-dead simple. To that end, it would not be possible > to flatten templates or apply defaults, or make any other change – it needs > to be as close as possible to a carbon-copy of the original intended > configuration (where deviations are allowed only for cases like a missing > line-card). To this end, yes, I think that we could tack on a statement > like the following: > > That is, the intended configuration is a subset of the applied > configuration where omissions are only due to when the > configuration cannot be applied (e.g., a missing line-card). > > What do you think? > I am wondering why operators would want to compare 2 massive subtrees in the first place, where 1 is static and the other is changing constantly. Do they really want this complex task or do they just want to determine if the intended config has been applied yet? Andy > > > >> - how does it relate to the state of the system after a equivalent > synchronous config commit (if at all)? > >> > > Again, I think that definition of requirement 1.D, along with the > proposed definition of synchronous configuration operation vs asynchronous > configuration operation, will provide a sufficient answer to this > question. I.e. that the state of the system after an asynchronous config > operation must, when fully synchronized, be the same as the state of the > system after an equivalent synchronous configuration operation completes > and replies back. > > [KENT] I agree with this, but I think it impacts issue #6 more so than > issue #4 - right? > > > Thanks, > Kent > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
