Ladislav Lhotka <lho...@nic.cz> wrote:
>
> > On 11 Jan 2016, at 15:58, Robert Wilton <rwil...@cisco.com> wrote:
> >
> >
> >
> > On 11/01/2016 14:27, Ladislav Lhotka wrote:
> >>> On 11 Jan 2016, at 15:11, Juergen Schoenwaelder
> >>> <j.schoenwael...@jacobs-university.de> wrote:
> >>>
> >>> On Mon, Jan 11, 2016 at 02:54:36PM +0100, Martin Bjorklund wrote:
> >>>> Ladislav Lhotka <lho...@nic.cz> wrote:
> >>>>> Hi Gert,
> >>>>>
> >>>>>> On 11 Jan 2016, at 14:25, Gert Grammel <ggram...@juniper.net> wrote:
> >>>>>>
> >>>>>> Lada,
> >>>>>>
> >>>>>> The requirement says:
> >>>>>> D. When a configuration change for any intended configuration
> >>>>>> node has been successfully applied to the server (e.g. not
> >>>>>> failed, nor deferred due to absent hardware) then the
> >>>>>> existence and value of the corresponding applied
> >>>>>> configuration node must match the intended configuration
> >>>>>> node.
> >>>>>>
> >>>>>> I don't see that this would limit the case you described below. In
> >>>>>> your case there is no intended config, hence there is no
> >>>>>> "corresponding applied configuration" either.
> >>>>> You are right, the requirement can be interpreted this way. I thought
> >>>>> that applied configuration was supposed to be identical to intended
> >>>>> after some synchronization period.
> >>>> This is a very important point to clarify. Can there ever be data in
> >>>> "applied" that is not in "intended"? I think Anees & Rob previously
> >>>> said "no", but I might be wrong.
> >>>>
> >>> If there is time delay between editing intended and the applied config
> >>> matching the edits of intended, then I supose this can happen (I
> >>> delete a resource from intended but it is still around until intended
> >>> has been fully synced). I would find it interesting if some edits are
> >> Using applied config for system-controlled entries would require that
> >> such an entry stays (forever) in applied config even after it has been
> >> deleted from intended.
> > I think that this would make life harder for clients.
>
> Hmm, I would say the opposite. For one, we could simplify the data
> models by reducing the duplicities in configuration and state trees.
This is the old idea of having the "operational state" datastore,
which would be all config true + all config false nodes. One issue
with this is that the semantics of the node is different in the
different data stores, even if the syntax (by definition!) is the
same. In order to handle this properly you need either two different
description statements, or two "sections" within the description
statement.
list interface {
description-config
"The list of configured interfaces on the device.
...";
description-oper
"The list of interfaces on the device.
System-controlled interfaces created by the system are
always present in this list, whether they are configured or
not.
...";
}
/martin
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
