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

[Joe Clarke <[e-mail]>]

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