Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)

Thanks Joe.  Yes, I meant I2RS CLIENT priority, not agent priority.
Yours,
Joel

On 7/20/16 5:30 AM, Joe Clarke wrote:
> On 7/20/16 05:24, Joel M. Halpern wrote:
>> That wording may well lead readers to think that Ephemeral
>> configuration, considered as a whole, has a priority.  Since that is not
>> true, I would like to further refine this.  How about:
>>
>> Req-07: Local configuration MUST have a priority that is comparable with
>> the I2RS Agent priority for making changes.  This priority will
>> determine whether local configuration changes or individual ephemeral
>> configuration changes take precedence.  The I2RS protocol MUST support
>> his mechanism.
>
> I think you mean I2RS client priority?  But otherwise, I like the text.
>
> Joe
>
>>
>> Yours,
>> Joel
>>
>> On 7/20/16 4:05 AM, Joe Clarke wrote:
>>> On 7/20/16 03:42, Susan Hares wrote:
>>>> Joe:
>>>> Yes - you are correct.  Can you help me state this requirement -07
>>>> better?
>>>
>>> What about:
>>>
>>> Ephemeral-REQ-07: Ephemeral configuration and local configuration MUST
>>> each have a priority.  This priority will determine whether ephemeral
>>> configuration or local configuration take precedence.  The I2RS protocol
>>> MUST support this mechanism.
>>>
>>> Is this clear and correct enough?
>>>
>>> Joe
>>>
>>>>
>>>> Sue
>>>>
>>>> -----Original Message-----
>>>> From: Joe Clarke [mailto:jclarke@cisco.com]
>>>> Sent: Wednesday, July 20, 2016 3:40 AM
>>>> To: Susan Hares; 'Russ White'; i2rs@ietf.org
>>>> Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
>>>> ephemeral)
>>>>
>>>> On 7/20/16 02:18, Susan Hares wrote:
>>>>> <WG hat off> <author hat on>
>>>>>
>>>>> Here's text that might replace it:
>>>>>
>>>>> Ephemeral-REQ-07: Ephemeral configuration state MUST be able to set a
>>>>> priority on local configuration and ephemeral state.  Based on this
>>>>> priority implementations MUST be able to provide a mechanism to choose
>>>>> which takes precedence. The I2RS Protocol MUST be able to support this
>>>> mechanisms.
>>>>>
>>>>> Any thoughts?
>>>>
>>>> I'm a bit confused by the first sentence.  I think what you're
>>>> stating is
>>>> that both ephemeral and local configurations MUST have a priority.
>>>> This priority will determine whether ephemeral configuration or local
>>>> configuration take precedence.  The I2RS protocol MUST support this
>>>> mechanism.
>>>>
>>>> Am I correct in my interpretation?
>>>>
>>>> Joe
>>>>
>>>>>
>>>>> Sue
>>>>>
>>>>> -----Original Message-----
>>>>> From: Russ White [mailto:7riw77@gmail.com]
>>>>> Sent: Wednesday, July 20, 2016 2:09 AM
>>>>> To: 'Joe Clarke'; 'Susan Hares'; i2rs@ietf.org
>>>>> Subject: RE: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
>>>>> ephemeral)
>>>>>
>>>>>
>>>>> (wg chair hat off) --
>>>>>
>>>>>> I think the idea of extending I2RS priority to local config operators
>>>>> (e.g., CLI)
>>>>>> will still work.  Let's take knob 1.  Knob 1 is kind of like the
>>>>>> on/off
>>>>> switch.  If I
>>>>>> don't want I2RS to have any effect on operational state, I'd have
>>>>>> this
>>>>> off.  In
>>>>>> the I2RS priority case, by default my local config could will have
>>>>>> the
>>>>> highest
>>>>>> priority (let's say that's 255 to make it concrete).  In this case no
>>>>> ephemeral
>>>>>> config can win.
>>>>>
>>>>> I wanted to extend Joe's remarks a bit... On reflection, I actually
>>>>> think having priority + "this wins" bits is rather confusing, and
>>>>> opens the door to all sorts of strange behavior. Say I have two items
>>>>> thus --
>>>>>
>>>>> Local config item -- priority 100
>>>>> I2RS config item -- priority 200, don't overwrite bit set
>>>>>
>>>>> If the higher priority is supposed to win, then which item should the
>>>>> operator find in the resulting running config? Should it be the I2RS
>>>>> version, because the priority is higher, or the local config, because
>>>>> the "don't overwrite" bit is set? There doesn't seem to be any clear
>>>>> way to interpret such a situation.
>>>>>
>>>>> It's better to have a single "thing" that determines which
>>>>> configuration among many wins, rather than two.
>>>>>
>>>>> -r
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> i2rs mailing list
>>> i2rs@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>
>