Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15)

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

Joe:

Let's start with the overview, and then go down to words. 

My concern: 
The phrasing of this impacts the OPSTATE discussions for Juergen.  Juergen
is pushing for ephemeral to just be operational state.  Other drafts are
pushing for ephemeral state to be configuration and ephemeral state.  I have
suggested a different model in the protocol-strawman for I2RS.  

What is important in this document is to indicate that ephemeral models have
both configuration and operational state.  

Words: 

This statement words for me in the beginning of section 3.  
/Ephemeral state is defined as potentially including in a data model
ephemeral configuration and operational state which is flagged as
ephemeral./

If this works, for you as well - I'll create a version 16. 

Sue  

-----Original Message-----
From: Joe Clarke [mailto:[e-mail]] 
Sent: Sunday, August 28, 2016 4:05 PM
To: Susan Hares; [e-mail]
Cc: [e-mail]; 'Alia Atlas'
Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to
8/15)

On 8/28/16 11:35, Susan Hares wrote:
>> I think this is good.  A general comment I have is that "ephemeral state"
> is used in a number of places where I think "ephemeral configuration" 
> should be used.  >This may be a nit, but the device has one state that 
> is dictated by the various configuration types and the operational 
> state.  This was raised in BA in the meetings >as well.
>
>> My recommendation is to replace "ephemeral state" with "ephemeral
>> configuration".   It's not a show-stopper the way it is, but I think the
>> latter is a bit clearer.
>
> We had agreed that "ephemeral state" as what is defined in section 3.  
> Do you think clarifying this in the text would be better:
>
> Old/Ephemeral state is defined as potentially including both ephemeral 
> configured state and operational state. / New/Ephemeral state is 
> defined as potentially including in a data model ephemeral 
> configuration state and operational state which is flagged as 
> ephemeral./
>
> Without this explicit comment, Juergen did not consider 
> Ephemeral-REQ--01 thru Ephemeral-REQ-04 to be specific enough.

To be clear, I think this is somewhat semantic.  A device has one state that
is made of a number of related things.  But this terminology not a stopping
thing for me.

In the new text above, would the following not satisfy Jürgen's comment?

/Ephemeral state is defined as potentially including in a data model
ephemeral configuration and operational state which is flagged as
ephemeral./

Note: I simply drop the second "state" as this seems a bit clearer to be
(i.e., before it stated, essentially, that ephemeral state includes
ephemeral state).

>> Section 7, bullet 2:  This text reads strangely:
>>
>> OLD TEXT:
>>
>> The I2RS protocol MUST support the
>>      ability to have data nodes MAY store I2RS client identity and not
>>      the effective priority of the I2RS client at the time the data
>>      node is stored.
>
>> PROPOSED NEW TEXT:
>>
>> The I2RS protocol MUST support the ability to have data nodes store 
>> I2RS
> client identity and not the effective priority of the I2RS client at
>> the time the data node is stored.
>
> Warning: I am re-writing the ephemeral-protocol-security-requirements 
> so, the reference in bullet may change.  You new text works for me.

Thanks and understood.

> Works for me (WFM):   The complete sentences would be:
>
> As part of this requirement, the I2SR protocol should support:

s/I2SR/I2RS/ :-)

>  - multiple operations in one or more messages; though errors in one 
> message or operation will have no effect on other messages or commands 
> even if they are related.
> - No multi-message commands SHOULD cause errors to be inserted into 
> the I2RS ephemeral state.

Works for me.

> If you confirm

Thanks, Sue.

Joe