Hi Alex,
What you describe is close, but not quite what either of the two
datastore solutions are proposing.
In this case, the two solutions in both proposed drafts would contain:
- intended config doesn't contain the list entries
- applied config doesn't contain the list entries
- operational state datastore contains the system created (config
true) list entries + descendant config false nodes.
The reason why these system created entries are not in the applied
configuration is because of the requirement from
draft-ietf-netmod-opstate-reqs state that "intended config" = "applied
config" if the system has converged and all configuration has been
successfully applied.
But, yes, the reason for allowing system created config true entries in
the operational state datastore is to solve this problem.
Rob
On 13/07/2016 10:49, Alex Campbell wrote:
Isn't that exactly what the proposed applied configuration datastore
is for?
If a device doesn't allow management stations to create or remove list
entries, but still creates or removes list entries itself, then it can
publish them through the applied configuration datastore, while
leaving the intended configuration datastore empty. Operational data
can be contained inside those list entries which exist in the applied
configuration store, instead of needing a separate tree to contain it.
- Alex
------------------------------------------------------------------------
*From:* netmod <netmod-boun...@ietf.org> on behalf of Andy Bierman
<a...@yumaworks.com>
*Sent:* Wednesday, 13 July 2016 4:17 a.m.
*To:* Lou Berger
*Cc:* netmod WG
*Subject:* Re: [netmod] OpsState Direction Impact on Recommended IETF
YANG Model Structure
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.
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)
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. 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
