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
