Yep. Tom
> On May 14, 2014, at 3:24 PM, Kent Watsen <[email protected]> wrote: > > > > Joel's "templates" sound like apply-groups in Junos: > > http://www.juniper.net/techpubs/en_US/junos13.3/topics/example/routing-matr > ix-tx-matrix-plus-using-configuration-groups-for-components-solutions.html > > K. > > > >> On 5/14/14, 10:28 AM, "Joel M. Halpern" <[email protected]> wrote: >> >> (Alia, correct me if I mis-represent this concept.) >> >> No, temnplating is not just "Default values must be possible to specify." >> >> An example is that you might have a scheduling structure. it has a set >> of defaults which create a specific scheduling discipling. >> The Client can create a scheduling instance, and can over-ride any and >> all of those defaults. >> So far, that is just modeling with defaults. >> >> The idea with templates is that the Client could also say "For all the >> values I don't specify, use the WFQ template" or the EF template, or ... >> If the client does that, the agent would treat the values from that >> template which are specified in the template and are not specified in >> the request from the controller as if they had been specified by the >> controller, rather than using the base defaults. >> >> Coupled with this, some mechanism would provide these templates. The >> power here is that there might be different templates for the "EF >> Scheduling template" on different boxes to reflect how each box should >> be configured to achieve the policy goal. >> >> Conversely, clearly, all of this data can be on the client and the >> client can do the inclusion. >> >> Yours, >> Joel >> >>> On 5/14/14, 9:58 AM, Jamal Hadi Salim wrote: >>> On Wed, May 14, 2014 at 8:42 AM, Joel M. Halpern <[email protected]> >>> wrote: >>>> Templating is described in the archtiecture document. >>>> However, as I said when i presented the material, this is a topic on >>>> which >>>> the authors disagree. >>>> I personally do not think it should be a protocol behavior, and >>>> therefore do >>>> not see it as something the model needs to represent. >>>> >>>> The basic idea of templating is to allow the I2RS client to say to the >>>> I2RS >>>> agent "I want to set this instance to these values, but for all the >>>> things I >>>> don't specify, use this template over here to determine what values to >>>> set." >>>> This clearly has power. Equally clearly, it can be done at the client >>>> rather than at the agent. >>> >>> Seems like i abused the term "template". I.e it seems to me that would >>> fall under >>> " Default values MUST be possible to specify" - which is described in >>> the wiki. >>> Shouldnt this be a model problem? >>> I will fix the wiki entry and remove it from that sub-section. >>> >>> On the OO class/instances: >>> The motivation is to be able to describe "set blah to RIB instance >>> foo". The >>> concept for abstracting a "factory" which is essentially a "class" vs >>> an "instance" of >>> that class seems to belong to the model. >>> >>> >>> cheers, >>> jamal >> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
