Maybe. I think that was the point though. Operationally you specify
these things, so as long as you can specify them we are good.
--Tom
> Ok, I think i get then what Joel was saying. Is this then an
> implementation issue?
>
> cheers,
> jamal
>
> On Wed, May 14, 2014 at 11:18 AM, Thomas Nadeau <[email protected]>
> wrote:
>>
>> Its not just default values; its more like a set of preconfigured
>> values for a set of objects.
>>
>> --Tom
>>
>>
>> On May 14, 2014:10:28 AM, 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
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
