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:[email protected]] On Behalf Of Joe Clarke Sent: Tuesday, August 2, 2016 12:38 PM To: Susan Hares; [email protected] Cc: [email protected]; '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 [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
