(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
