Andy,
This may be a bit OBE by the conversation on the list, but see below...
On 7/12/2016 12:17 PM, 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.
>
The config/state split discussed in the context of opstate, and the
openconfig draft in particular, reflects two different types of separations:
1) configuration vs operational information (e.g., intf parameter vs
counters)
2) intended vs applied configuration
My earlier comment about assuming that we're getting rid of -config and
-state (as part f the decision to move to revised datastores) was really
focused on the second.
> Most of the foo-state variables are for monitoring.
I really wasn't commenting on conventions WRT configuration data and
operational parameters relationship/organization -- although I think
having a general convention for these is "a good idea".
> 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?
>
>
Again, I was focusing on the intended vs applied aspects here. I can
see reasons to keep a top level spit for config vs operational state,
but alos don't have a strong personal bias on this.
Lou
> Andy
>
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
