Hi,

Andy Bierman <[email protected]> wrote:
> Hi,
> 
> thanks.
> A few details of the solution I am working on...

I would (still!) use a new statement "i2rs:ephemeral true;" to mark
ephemeral nodes on config false nodes.  This can be done w/o changing
YANG.

> 1) defaults are not used in the ephemeral datastore
> 
> The default-stmt is altered for the ephemeral datastore.
> Default leafs are ignored (except for XPath evaluation).
> Otherwise the schema default would always override the configuration.

I see your point, but if I create a list instance entirely in the
ephemeral data store, I would assume defaults in that list instance to
be used.

I think the logic should be that if no value is set in the config or
ephemeral, then the default value is used.  The ephemeral value
overrides the configured value.

> 2) XPath hierarchy is based on config-stmt.
> 
>   config=true context node -> can reference config=true
>   config=ephemeral context node -> can reference true + ephemeral
>   config=false context node -> can reference true, ephemeral, false
> 
> 3) must/when evaluation applies only to the datastore indicated by
> config-stmt
>      config=true -> running
>      config=ephemeral -> ephemeral
>      config=false -> operational
> 
> 4) panes of glass applied to data instances
>     all running datastore instances are visible in the ephemeral datastore
>     all ephemeral datastore instances are visible in the operational
> datastore
> 
> 5) admin-foo and oper-foo can go away

Yes, but I assume that they don't *have* to go away.  For example, the
duplex example would still have two nodes, since the syntax is
different.

>   The instance of 'admin-temp' in the operational datastore would return
>   the value in effect, not the desired value, so 'oper-temp' is not needed
>   and the correlation between config, ephemeral, and operational is
> maintained
>   in the common instance-identifier in all 3 datastores


/martin

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to