Hi Andy,
On 12/07/2016 17:17, Andy Bierman wrote:
On Tue, Jul 12, 2016 at 8:23 AM, Lou Berger <lber...@labn.net
<mailto:lber...@labn.net>> wrote:
Acee,
I personally was assuming we'd follow 3, but I'd like to
understand
the implication of 2 as I'm not sure I really understand what you're
thinking here. Can you elaborate what you're thinking here?
Thanks,
Lou
.....
> 3. #2 plus collapse the config (read-write) and system-state
> (read-only) into common containers. No more branching of
> <model-name>-config and <model-name>-state at the top level of
the model.
>.....
I would really like to understand what problem (3) is supposed to solve.
My personal view is that I think that it makes the models simpler, with
less duplication.
E.g. I also see that it makes it easier for a client to fetch all of the
information associated with a particular feature in a single sub tree
rather that needing to merge data from two separate config & state sub
trees.
Most of the foo-state variables are for monitoring.
This information is useful even if the server uses proprietary
configuration mechanisms.
(e.g., the way the SNMP world has worked for 30 years)
I thought that it was config that was originally driving YANG because
there is already a solution for state data (SNMP). Hence, I would have
thought that the most common case would be that YANG is used just for
config, or config & state. So, I think that it makes sense to optimize
models for these scenarios.
If you forbid separate monitoring subtrees and force the data to be
co-located
with configuration, that means the standard monitoring will not be
supported
unless the standard configuration is also supported.
Both datastore draft solutions allow for system created config entries.
So in both drafts the operational state datastore can instantiate
whatever config nodes are necessary to parent config false state nodes.
I also don't think that separate monitoring subtrees are going to be
banned, they should be used where appropriate. It is just that it will
be no longer be required to have separate state subtrees purely because
of potential differences in the lifetime of config vs state objects
(e.g. interfaces vs interfaces-state).
I would be very happy if "interfaces" and "interfaces-state" could be
merged into "interfaces" as a new/updated interfaces YANG model that
draft models could be updated to use. I understand that would be a
impactful change to make (but seemingly mostly on IETF models that
haven't yet been standardized). But I hope that we are going to have to
live with the YANG model structure for a long time, and if we still have
an opportunity to "fix" a fairly big wart then I think that it would be
good to do so.
Rob
Why is that progress?
Andy
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
