On Mon, Dec 13, 2021 at 3:44 PM Kent Watsen <[email protected]> wrote:

> Juergen/Andy,
>
>
> Option #3
>>
>> There is a client on the system that makes changes to running just
>> like any other remote clients can make changes to running. System
>> generate config that is not editable explicit config in running goes
>> straight into the applied config in operational. This does not require
>> a system datastore (in fact something like a system datastore may
>> exist as the _logic_ of the system client, the good old example we had
>> is allocting an unused uid for an account that, once allocated, is
>> maintained in running).
>>
>>
> Juergen, you mentioned this before.  I don’t recall if there were any
> responses, but how would this solution address the various concerns that
> have been raised?
>
>
> +1 to option 3.
> Consider an implementation that moves all the "hidden system logic" off-box
> to a controller, such that the initial config is literally supplied by an
> external client.
>
>
> Andy, IIRC, you +1’ed Juergen’s previous “option #3”, but can you to
> answer the same question about how solution address concerns?
>
>
I do not have any problem with <running> containing active and inactive
nodes.
That's what has been in place for over 10 years. That's what is written in
NMDA.
I cannot find any RFC text that says <running> has only nodes created by a
client.
I cannot find any RFC text that says system-injected config is special,
especially since
server implementations exist that treat these edits as just another client
(although probably a 'root' user client).

Rewriting NMDA and YANG validation to add a new <system> datastore is
a major change that will impede deployment. The IETF already had 1 "do-over"
because of NMDA.  Not so sure a 2nd do-over is going to go over well.

Andy


> I have yet to hear a single use-case for creating a <system> datastore.
> "The client might want" is not a use-case for standardization.
> I do not understand the "pure view". Seems like if this was a real problem
> to solve,
> then NMDA would have included a system datastore from the start.
>
>
> Use-cases and issues were discussed at both the Interim and at IETF 112.
> I don’t recall you or Juergen attending either, but the 112-recording
> starts at the 23-minute mark here:
> https://play.conf.meetecho.com/Playout/?session=IETF112-NETMOD-20211111-1430
>
>
> K.  // as a contributor
>
>
>
>
>
>
>
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to