[Xufeng] Right. If we do so, the approach will be different from RFC7223, and
requires the capability that a "config true" leafref references a "config
false" leaf.
I think my proposal was misunderstood, so here's a more complete example:
Assume the following schema is used by client/servers that implement the
long-term
opstate solution presented in the revised-datastores draft:
module foo {
container nodes {
config true;
list node {
key "name";
leaf name { type string; }
leaf dependency {
type leafref {
path "../node/name"
require-instance false;
description
"In the case when a configured node (i.e. in the running DS)
has a dependency on a node that is not configured, the
system
may try to resolve the dependency as operational state data
(i.e. in the operational-state DS). As operational state
data may have a lifecycle independent of configuration,
there
is no guarantee that the opstate data will exist.
Therefore,
application of the configuration node is conditional,
resulting
in an effect much like pre-provisioning interfaces in RFC
7223.";
}
}
}
}
}
Specifically, note that the leafref is from one config true node to another
config
true node. I understand that the semantics are almost as if it were like a
config
true node were pointing to a config false node, but I believe that this should
be
okay, that is, that we should specifically define this convention as okay.
Assuming that we're okay with the above, we proposal for a near-term solution,
that
does NOT utilize the opstate solution, follows:
module foo {
container nodes {
config true;
list node {
key "name";
leaf name { type string; }
leaf dependency {
type leafref {
path "../node/name"
require-instance false;
description
"In the case when a configured node (i.e. in the running DS)
has a dependency on a node that is not configured, the
system
may try to resolve the dependency as operational state data
(i.e. under the /nodes-state tree). As operational state
data may have a lifecycle independent of configuration,
there
is no guarantee that the opstate data will exist.
Therefore,
application of the configuration node is conditional,
resulting
in an effect much like pre-provisioning interfaces in RFC
7223.";
}
}
}
}
container nodes-state {
config false;
list node {
key "name";
leaf name { type string; }
leaf dependency {
type leafref {
path "../node/name"
require-instance false;
}
}
}
}
}
This module is semantically identical to the first, but now, in additional
to the leafref potentially hopping datastores, it also needs to hop paths
(i.e. s/nodes/nodes-state/). Note the minute change in the first sentence
of the description statement. Yes, it's a hack, but since the hopping is
implemented internally anyway, maybe it's okay as a stop-gap short-term
solution?
Kent
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
