Hi,
"Acee Lindem (acee)" <[email protected]> wrote:
>
> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
> <[email protected] on behalf of [email protected]> wrote:
>
> >
> >> On 23 Dec 2015, at 04:06, Kent Watsen <[email protected]> wrote:
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
> >><[email protected] on behalf of [email protected]> wrote:
> >>
> >>>
> >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
> >>>><[email protected]> wrote:
> >>>>
> >>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
> >>>>
> >>>>> I hope that nobody disagrees that the operational state design and
> >>>>>how
> >>>>> to structure the models are the two blocking factors to publish YANG
> >>>>> models. If you disagree or don't see this, let me know, I should
> >>>>> communicate better.
> >>>>
> >>>> Even if it may spoil your day, I disagree that there is a blocking
> >>>> factor that should stop us from publishing models. There seem to be
> >>>> ways to address the requirements without having to block all work or
> >>>> to redo what that we have published. But sure, if you make it a
> >>>> blocking factor, it will be one.
> >>>
> >>> I agree with Juergen. It is not clear to me how the proposed split
> >>>between intended and applied configuration is supposed to affect the
> >>>data models we are working on.
> >>
> >>
> >> As I understand it, solution #1 affects the models themselves, whereas
> >>solutions #2 and #3 are transparent to the models.
> >
> >Then #1 looks like a non-starter to me.
>
> I’d like to point out that we also have the requirement to allow retrieval
> of derived-state along with intended-config and applied-config. This will
> require modification to most of the existing YANG drafts as most now have
> separate trees for config and operational state.
I don't agree with the conclusion that changes are needed due to this
requirement.
Solution #1 ("openconfig") requires changes to handle applied config.
Solution #2 ("kent's") does not.
Both solutions #1 and #2 use separate nodes for derived state.
It might appear as #1 and #2 are very different in their handling of
derived state, since #1 put all config false nodes directly under the
config true nodes, whereas #2 in some cases have a top-level
"xxx-state" config false node.
But in fact #2 allows the solution in #1 as one special case. The
reason that RFC 7223 has a separate list for derived state interfaces
is to allow for non-configured interfaces to be monitored. If this
was not a requirement, all config false nodes could (would) have been
defined in the config true interface list.
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
