Hi Susan,
this document looks very good & I clearly support it.
Just two very minor comments:
- editorial nits - page 2: "Sections 7" --> "Section 7"; "is I2RS
protocol requirement" --> "is an I2RS protocol requirement"
- I consider Ephemeral-REQ-03 as very important ("may have constraints
that refer to operational state"). I am wondering, should the draft mention
how to deal with the fact that it is possible for operational state to
dynamically change. I would think it is might be worth stating something to
the effect that constraints should be assessed when ephemeral state is written,
and that situations are conceivable where violations of such constraints might
occur due to changing of operational state after the write occurred. By the
nature of the issue, the framework must allow for that; how to deal with such a
situation and maintain integrity of the ephemeral configuration in such cases
is up to the client.
One thought re: section 9, clearly we have a requirement to support
subscriptions against ephemeral data; is there a requirement for subscriptions
to be ephemeral themselves? (I think it is implicitly supported via dynamic
subscriptions.)
Thanks
--- Alex
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
