On Wed, May 14, 2014 at 7: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. > A generic template feature would be interesting, and may not be a lot of work. If a template includes lots of data, then it could be much faster (CPU, on-the-wire) than inline edits. Templates are usually just for convenience and consistency, but consistency (even across clients) is important. In the generic sense, a YANG template would be a sub-tree without keys. Whatever nodes were missing from the client request would get merged in by the server. (Some NETCONF servers are designed to do this merge very quickly). The protocol operation would say "edit that data with this patch and template X". > Yours, > Joel > Andy > > 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
