"Susan Hares" <[email protected]> wrote:
> This begins a 2 WG LC last call on the text of
> draft-ietf-i2rs-ephemeral-state-10.txt.
Hi,
I have reviewed draft-ietf-i2rs-ephemeral-state-11, and here are my
comments.
o Ephemeral-REQ-02
I suggest you remove the text:
it SHALL be considered a validation error if it does.
The requirement is clear as it is without this. And maybe the
solution will make sure it is not even syntactially possible to
define such constraints.
o Ephemeral-REQ-03
I think you need to define what you mean with "constraint". For
normal config, YANG has very detailed rules about when constraints
are checked and what a server MUST do when a constraint becomes
false.
Since this requirement says that constraints can refer to fast
changing state, you need to say what should happen if such a
constraint suddenly becomes false due.
o Ephemeral-REQ-04
The requirement says that ephemeral state can refer to
non-ephemeral state in constraints. Does the term "non-ephemeral
state" include configuration? If so, does this mean that if an
operator tries to delete some config, the existance of some
ephemeral state may reject the config change request?
o Ephemeral-REQ-07
This requirement says:
"Implementations MUST provide a mechanism..."
Does this mean that this mechanism should not be standardized;
rather implementations are required to invent some vendor-specific
mechanism?
o Ephemeral-REQ-08
I understand "ephemeral" and "read/write". But what does
"status/configuration" mean in this context? Can I have
"ephemeral, read-only, configuration"? Can I have
"ephemeral, write, status"?
o Ephemeral-REQ-09
This requirement is fine, but why is it labeled *changes* to
NETCONF? NETCONF already supports this requirement.
o Ephemeral-REQ-10
This requirement is fine, but why is it labeled *changes* to
RESTCONF? RESTCONF already supports this requirement.
o Ephemeral-REQ-13
I do not understand what this requirement means.
(BTW, the text should be rephrased; it now says "the requirement
... is required ...")
o Ephemeral-REQ-14
If this is not a new requirement, does it need to be part of this
document?
If the answer is yes, are there other things from the architecture
document that should be listed here, e.g., details about priority
interaction w/ local config?
o Ephemeral-REQ-15
I do not understand what this requirement means.
o general
s/Yang/YANG/g
/martin
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
