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

On Wed, Jul 11, 2018 at 4:22 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> Kent Watsen <kwatsen@juniper.net> 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.

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.

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?
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.

> 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
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>