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

On 7/20/16 05:31, Joel M. Halpern wrote:
> Thanks Joe.  Yes, I meant I2RS CLIENT priority, not agent priority.

Sounds like that is what we're going to kick back to the list (i.e., 
your text s/agent/client/).  Thanks, Joel.

Joe

> 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
>>>>
>>