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

["Susan Hares" <[e-mail]>]

Joe: 
Yes - you are correct.  Can you help me state this requirement -07 better? 

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