Martin,
To be clear -- I'm not proposing any changes to YANG or NETCONF. I was
merely trying to write down the discussion that we had on one of the
interims about ways that 'datastores' may be considered by some
implementations, particularly as this view can mean that they might be
able to ignore them - based on the current ones that are implemented.
Martin Bjorklund wrote:
Even if we had the four separate datastores 'startup', 'running',
'candidate', and 'applied', it is not entirely clear to me why the
datastore would have to be carried together with the path internally
all the time. (We do not carry the current datastores in our system
today). Maybe this is an implementation issue?
Sure, it does not have to be carried all the time, but is /is/ required
in some cases. If one wants a standardised 'path' format to be passed
between systems then there's going to need to be space for the
'datastore' to be carried in path references that are handed about (even
if there is a 'default' datastore). I, for one, would find it messy if
there needs to be context specific ways of handling what a path looks like.
I find the fact that there can be ambiguity for a certain path something
that is quite different from all other systems, and hence consider it to
be suboptimal when compared to having a unique path to a particular set
of data. Having a path that can result in different values being
returned seems fragile.
Best,
r.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
