On 8/28/16 16:20, Susan Hares wrote:
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.
Agreed.
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.
Yes, this works.
Joe
Sue
-----Original Message-----
From: Joe Clarke [mailto:[email protected]]
Sent: Sunday, August 28, 2016 4:05 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/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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
