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

[Joe Clarke <[e-mail]>]

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:[e-mail]]
> Sent: Wednesday, July 20, 2016 3:40 AM
> To: Susan Hares; 'Russ White'; [e-mail]
> 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:[e-mail]]
>> Sent: Wednesday, July 20, 2016 2:09 AM
>> To: 'Joe Clarke'; 'Susan Hares'; [e-mail]
>> 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
>>
>>
>
>