On 12/07/2016 18:05, Andy Bierman wrote:
On Tue, Jul 12, 2016 at 9:59 AM, Robert Wilton <rwil...@cisco.com
<mailto:rwil...@cisco.com>> wrote:
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.
This is your opinion.
I think separate makes it easier to read, especially if the monitoring
data
is relevant regardless of how associated configuration was done.
This is easily achievable by filtering (e.g. only return config false
leaves + config true structural nodes).
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.
This is marketing.
Do you have any technical arguments?
Yes, I gave them below: I don't see that merging config and state
prevents entities from only monitoring state if they wish.
Thanks,
Rob
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.
I can't say if the pre-provisioning model in ietf-interfaces should be
generalized.
I have not seen any good general solutions for combining config and state.
Rob
Andy
Why is that progress?
Andy
_______________________________________________
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
