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

From: "Susan Hares" <[email-masked]>
Date: Tue, 2 Aug 2016 09:18:24 -0400

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. 

Sue Hares and Russ White

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 2 Aug 2016 15:54:33 +0000

I think this draft is ready for RFC. No more comment.

Linda Dunbar

From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, August 02, 2016 8:18 AM
To: [email-masked]
Cc: [email-masked]; 'Alia Atlas'
Subject: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15)

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.

Sue Hares and Russ White

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 2 Aug 2016 12:03:36 -0400

<author hat on> 

+1 to Linda's comment.  No IPR in the document. 

</author hat off> 

From: i2rs [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, August 2, 2016 11:55 AM
To: Susan Hares; [email-masked]
Cc: [email-masked]; 'Alia Atlas'
Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to
8/15)

Linda Dunbar

Sue Hares and Russ White

---

From: Joe Clarke <[email-masked]>
Date: Tue, 2 Aug 2016 12:37:51 -0400

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.

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

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.

Section 8: I2RS is written "I2SR"

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

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

Joe

---

From: "Russ White" <[email-masked]>
Date: Tue, 2 Aug 2016 13:28:48 -0400

<chair hat off>

This doc looks ready for publication to me...

:-)
Russ

> -----Original Message-----
> From: Susan Hares [mailto:[email-masked]]
> Sent: Tuesday, August 2, 2016 9:18 AM
> To: [email-masked]
> Cc: [email-masked]; 'Alia Atlas' <[email-masked]>
> Subject: 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15)
> 
draft

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 2 Aug 2016 14:59:39 -0400

This document appears to me to accurately reflect the working group 
agreed requirements.  It also appears to be a a clear and effective 
statement of these requirements, which I support.

Thus, I support publication of this document as an RFC.

Yours,
Joel

On 8/2/16 9:18 AM, Susan Hares wrote:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 3 Aug 2016 09:26:48 +0000

This document reflects the consensus hummed at IETF 96. I am fine with its content.

Regards,

Dan

From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, August 2, 2016 4:18 PM
To: [email-masked]
Cc: [email-masked]; 'Alia Atlas'
Subject: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15)

Sue Hares and Russ White

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 5 Aug 2016 06:39:29 +0000

Hi,

I support the publication of this document as an RFC.

Best regards,
Jie

From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, August 02, 2016 9:18 PM
To: [email-masked]
Cc: [email-masked]; 'Alia Atlas'
Subject: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15)

Sue Hares and Russ White

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 28 Aug 2016 11:35:47 -0400

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-masked]] On Behalf Of Joe Clarke
Sent: Tuesday, August 2, 2016 12:38 PM
To: Susan Hares; [email-masked]
Cc: [email-masked]; '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:
>> draft received a "hum" of consensus at IETF 96, and we are now taking 

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

>configuration".   It's not a show-stopper the way it is, but I think the 

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. 

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

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.

>requirements SHOULD be understood to be expanded to include

Works for me (WFM). 

If you confirm

---

From: Joe Clarke <[email-masked]>
Date: Sun, 28 Aug 2016 16:05:15 -0400

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

> the reference in bullet may change.  You new text works for me.

Thanks and understood.

> As part of this requirement, the I2SR protocol should support:

s/I2SR/I2RS/ :-)

> - No multi-message commands SHOULD cause errors to be inserted into the I2RS

Works for me.

> If you confirm

Thanks, Sue.

Joe

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 28 Aug 2016 16:20:18 -0400

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:[email-masked]] 
Sent: Sunday, August 28, 2016 4:05 PM
To: Susan Hares; [email-masked]
Cc: [email-masked]; '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:
> 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.
>
> We had agreed that "ephemeral state" as what is defined in section 3.  
> Do you think clarifying this in the text would be better:
>
> 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.

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

s/I2SR/I2RS/ :-)

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

Works for me.

Thanks, Sue.

Joe

---

From: Joe Clarke <[email-masked]>
Date: Sun, 28 Aug 2016 16:32:51 -0400

> both configuration and operational state.

Agreed.

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

Yes, this works.

Joe

---

From: "Susan Hares" <[email-masked]>
Date: Sun, 28 Aug 2016 16:54:30 -0400

Joe: 

I will send out version 16 shortly. 

Sue 

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

On 8/28/16 16:20, Susan Hares wrote:
> 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.

Agreed.

Yes, this works.

Joe

>>> I think this is good.  A general comment I have is that "ephemeral
state"
>> 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.
>>
>> 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 
> 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.
>
> 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).
>
>> message or operation will have no effect on other messages or 
>> commands even if they are related.