Kent, >From the 5000 foot view, this looks to me like the description changing the behavior of what a system should do.
What am I missing? Thanks, Alia On Fri, Feb 3, 2017 at 1:11 PM, Kent Watsen <[email protected]> wrote: > > [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 >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
