Hi,
Kent Watsen <[email protected]> wrote:
> [As an individual contributor]
>
> In preparation for our Virtual Interim meeting this Thursday, my
> primary goal was to understand the problems needing to be solved.
> Hopefully this isn't too much of a simplification, but there seems to
> be just the single core issue:
>
> - no programatic mechanism to relate running state to intended
> state (configuration). Currently, management systems must
> code to the text found YANG description statements.
I also re-read this document yesterday, and I agree with this
conclusion.
Note that section 5.19 of the recently published
draft-ietf-netmod-rfc6087bis-03 contains text that tries to illustrate
some of the issues around the problem of associating state with
config.
> The draft then puts forth a a number of recommendations to address the
> issue including:
>
> - recommendation to put state in leafs
> - recommendation to use a naming convention
> - recommendation to have statement like operational true/intent/false
> - recommendation to add to YANG a map statement (since lists don't
> - support deep keys)
> - recommendation to allow config=true inside config=false containers
>
> Some parts of the draft did not make sense to me. For instance, the
> synchronous vs asynchronous discussion didn't seem to be connected to
> the solution.
I am also confused by the terms "intended config" and "actual
config", and the lifecycle of these objects in an asynchronous
system. Is the idea that every leaf that you can configure exists in
three different places:
o as "actual config" (under the "config" container)
o as "intended config" (under the "state" container)
o as "operationally used value" (also under the "state" container,
but presumably with a different name?)
When a client tries to set this leaf in an asynchronous system, will
the "intended config" value be set first, then the "actual config",
and lastly the "operationally used value"?
The examples in the document don't reflect this, so maybe I didn't get
it right.
/martin
> Same for the desire to have an asynchronous push
> notification mechanism. Separately, I don't agree that receiving
> NETCONF RPC-reply <ok/> means that the intended configuration is
> operational, so much as "received by the server". I also don't agree
> that every configured value has op-state - e.g., consider a server's
> hostname.
>
> Overall I agree that it would be nice if there was a programmatic
> mechanism to relate intended and configured state, even if only for
> state nodes that are identical to configured nodes. But I m
> struggling to understand the importance of supporting generic clients
> that do not understand the semantics of a model well enough to know
> where and how to consume its operational state.
>
> Thanks,
> Kent
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
