Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

[Alia Atlas <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>