Re: [Netconf] nmda-restconf operations (was: netconf-binary-encoding comments)

[Ladislav Lhotka <[e-mail]>]

Andy Bierman <[e-mail]> writes:

> On Wed, Jul 11, 2018 at 10:16 AM, Ladislav Lhotka <[e-mail]> wrote:
>
>> On Wed, 2018-07-11 at 08:40 -0700, Andy Bierman wrote:
>> >
>> >
>> > On Wed, Jul 11, 2018 at 4:22 AM, Ladislav Lhotka <[e-mail]> wrote:
>> > > Kent Watsen <[e-mail]> writes:
>> > >
>> > > >>> This isn't what I meant.  To be more specific, I'm wondering if the
>> > > nmda-restconf
>> > > >>> draft would benefit from having a sentence like:
>> > > >>>
>> > > >>>    A RESTCONF server supporting NMDA datastores MAY implement the
>> > > >>>    "ietf-netconf" [RFC6241] and "ietf-netconf-nmda" [I-D.
>> ietf-netconf-
>> > > nmda-
>> > > >>>    netconf] modules to enable the NETCONF operations defined in
>> those
>> > > >>>    drafts to appear {+restconf}/operations resource.
>> > > >>>
>> > > >>> Note: I put "MAY" as RESTCONF may someday have a more native way
>> to do
>> > > this.
>> > > >>>
>> > > >>
>> > > >> Well, "ietf-netconf" does not really support NMDA well and this is
>> why
>> > > >> we have "ietf-netconf-nmda". Does not make much sense to point to
>> > > >> "ietf-netconf" in an NMDA document.
>> > > >
>> > > > But we'd still need lock, unlock, commit, commit-confirmed, etc.,
>> > > > right?
>> > >
>> > > These would make RESTCONF server stateful, thus violating REST
>> principles.
>> > > My
>> > > draft
>> > >
>> > > https://datatracker.ietf.org/doc/draft-lhotka-netconf-
>> restconf-transactions/
>> > >
>> > > tries to achieve similar effects in a RESTful way.
>> > >
>> >
>> >
>> > I like the idea of "private candidate" datastores you call "staging".
>> > I would keep the term candidate.
>>
>> The problem with this is that <candidate> in NETCONF has a looser
>> semantics (it
>> can also be shared).
>>
>> >
>> > This idea was discussed during RESTCONF draft development, but
>> > as the client creating a "transaction" resource. I think your draft is on
>> > the right track, and datastores are protocol-independent so NETCONF
>> > can use the same datastores with RPC operations.
>>
>> Yes, it can certainly be improved. I already have some pending updates,
>> but I
>> wanted to keep it simple for start.
>>
>> >
>> > You ignore the problem of concurrent edits, which is why this idea was
>> not
>> > pursued
>> > at the time. What happens when the altered data overlaps across private
>> > candidates?
>>
>> I don't ignore it, the text says that the user's staging datastore has to
>> be
>> atomically merged into <intended>, I just didn't want to specify the
>> procedure.
>> In any case, the result has to be a valid <intended>. But I am open to a
>> discussion.
>>
>
>
> Leaving it as an implementation detail is the IETF's way of ignoring
> problems.

Here, the situation may be further complicated by factors that are not
present in git, such as NACM or validation issues. But in fact, the
particular procedure is not so important from the protocol viewpoint:
by issuing the commit operation, the client says: "Dear server, here is
my intention how the configuration should look like, do whatever you can
to merge it with the existing config."

>
>
>>
>> > What are the procedures equivalent to git pull, push, merge?
>> > How are collisions handled? What exactly is a collision?
>> > Not trivial standards issues to solve.
>>
>> I think it can be left open, I even suspect there is no universal solution
>> suitable for all use cases. Our implementation (JetConf) does the
>> following:
>>
>> - each user's edit operation is applied to the staging datastore and also
>> recorded in a journal
>>
>> - at commit, if <intended> hasn't been changed in the mean time, then the
>> staging datastore simply becomes <intended>
>>
>> - otherwise, the edit operations from the journal are applied sequentially
>> on
>> the actual contents of <intended>.
>>
>>
>
> This is "last one wins".

No, as I wrote, if an operation writes data that were changed in the
mean time, the commit fails.

Lada

> You will find this sort of works for create and merge but no so much for
> replace and delete.
>
>
>
>> (Actually, we are not NMDA-compatible yet and don't have <intended> but it
>> works
>> this way).
>>
>> Lada
>>
>
>
> Andy
>
>
>>
>> >
>> > > Lada
>> > >
>> >
>> >
>> > Andy
>> >
>> > > >
>> > > > Maybe it's a moot point, since ietf-netconf-nmda requires that ietf-
>> > > netconf
>> > > > is implemented too, but I thought being explicit would be helpful
>> here.
>> > > >
>> > > > So, adding something like this to nmda-restconf would be good?
>> > > >
>> > > >
>> > > > Kent // contributor
>> > > >
>> > > > _______________________________________________
>> > > > Netconf mailing list
>> > > > [e-mail]
>> > > > https://www.ietf.org/mailman/listinfo/netconf
>> > >
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67