Joe:

I'm sorry I missed responding you on August 2nd.  It appears I wrote the
message and then did not send it.    Please see comments below.  All changes
except the ephemeral state--> ephemeral configuration work for me (WFM).
Would you take a moment to look at that point, and then I will release a
version with the changes. 

Sue 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joe Clarke
Sent: Tuesday, August 2, 2016 12:38 PM
To: Susan Hares; i2rs@ietf.org
Cc: russ@riw.us; 'Alia Atlas'
Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to
8/15)

On 8/2/16 09:18, Susan Hares wrote:
>> This begins a 2 week WG LC on draft-i2rs-ephemeral-state-15.txt.  This 
>> draft received a "hum" of consensus at IETF 96, and we are now taking 
>> the final text to a WG Last Call.  Please send your comments on the 
>> requirements to the WG list.

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

>One nit I notice is a mixed use of Client/client Agent/agent.  Per the last
round of RFCs, we are normalizing on client and agent (lowercase).

I will fix in version-16.  You are correct.  After we agree upon the use of
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. 

>Section 8: I2RS is written "I2SR"
I will fix in version -16 of the text.  Thank you. 

>Section 8: This text is odd
>OLD TEXT:
>multiple operations in one or more messages handling can handle
>     errors within the set of operations in many ways.

>I'm stumped.  This doesn't read as a requirement per se.  Yes, the I2RS
protocol can support multiple operations within one message or multiple
messages.  Based >on the fact that atomicity is not provided, an error in
one message will have no effect on other messages, even if they are related.
So maybe:
>PROPOSED NEW TEXT:
>
>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

Works for me (WFM):   The complete sentences would be: 

As part of this requirement, the I2SR protocol should support:
 - 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.

>Section 9:
OLD TEXT:
>requirements SHOULD be understood to be expanded to to include
>
>NEW TEXT:
>
>requirements SHOULD be understood to be expanded to include

Works for me (WFM). 

If you confirm 

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs