Martin Bjorklund <m...@tail-f.com> writes:
> 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.
I think this is not much different from default values. Leafs and
leaf-lists that have them defined in the data model may not be present
in intended config, yet one can consider them to be in applied config.
Lada
>
> 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
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
