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

On 7/20/16 05:10, Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) 
wrote:
> Hi,
>
> Sorry, but I can't make the I2RS meeting because I'm presenting at the
> end of NETCONF.
>
> I've spoken to Sue and understand that the requirement isn't changing
> here - just the text to describe it.
>
> I think that I'm OK with this new text.
>
> One suggestion: Possibly It might help if the text made it clear that
> the priotiy resolution applies to the complete set of ephemeral config
> vs the complete set of local config. I.e. the requirement is not asking
> for priority resolution between the two config sets on a per datanode basis.

Yes, I had assumed that in my text, but I agree, this should be clear.

Functionally, in my head, I imagine local config to act like an I2RS 
client.  Clients don't have a per-data node priority.  They have an 
overall priority.

Is this consistent with what you're stating here?

Joe

>
> But I strongly support getting the requirements draft completed, and
> hence I suspect that whatever text that you agree in the 2nd I2RS
> meeting will be fine.
>
> Thanks,
> Rob
>
>
> Sent from my Xperia™ tablet
>
> ---- Joe Clarke (jclarke) 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