Hi Joel, Just quickly, the key point is to avoid having the client need to understand all the different ways of making the desired behavior happen or specifying all the details when there's only a small set that need to change.
A use-case is something like assigning traffic into a particular queue or configuring that queue where there aren't good and common abstractions. Alia On Wed, May 14, 2014 at 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
