Re: [netconf] RESTCONF support in private candidates draft

On Mon, Feb 5, 2024 at 4:32 AM Robert Wills (rowills) <rowills=
40cisco.com@dmarc.ietf.org> wrote:

> Hi Netconf Working Group,
>
>
>
> After James and I presented an update on draft-ietf-netconf-privcand-01 at
> IETF 118, Kent asked about RESTCONF support in the draft, and specifically
> about the lifecycle of a private candidate when using RESTCONF. This email
> is to follow up on that question, and to ask the Working Group whether
> RESTCONF support should be kept in this draft.
>
>
>
> Currently, the draft states that
>
>
>
> "When a private candidate is used by RESTCONF, it exists only for the
> duration of the RESTCONF request." (draft-ietf-netconf-privcand-01 Section
> 2.3).
>
>
>
> Later, the draft expands on this by stating that changes made to a private
> candidate will be committed as part of the same request:
>
>
>
> "When the server advertises the :private-candidate capability and the
> client does not explicitly reference a datastore in their request, all
> edits are made to a new private candidate, and the private candidate is
> committed. This is analagous to the behavior of RESTCONF when the
> :candidate capability is specified by the server.
>
>
>
> "When the private-candidate datastore is explicitly referenced, edits are
> made to a new private candidate and the private candidate is committed."
>
>
>
> (draft-ietf-netconf-privcand-01 Section 4.4.3)
>
>
>
> This wording is intended to preserve the high-level goal of private
> candidates, namely allowing multiple clients to make independent
> configuration changes, and to behave similarly to RESTCONF's current
> behavior for the (shared) candidate. (RESTCONF RFC 8040 Section 1.4: "The
> candidate MUST be automatically committed to running immediately after each
> successful edit").
>
>
>
> As far as I'm aware, RESTCONF doesn't currently have a mechanism for
> editing a datastore and then committing the changes in a separate request.
> The authors wanted to avoid having to specify such a mechanism, partly
> because neither of us are RESTCONF experts, and partly because it could
> also apply to other datastores (such as the “shared” candidate).
>
>
>
> If more work is needed on the RESTCONF support for the private candidate
> datastore, I think it would be better to remove RESTCONF from this draft
> and address it in a separate draft later, with an author who's a RESTCONF
> expert.
>
>
>
> Thoughts and comments are very welcome.
>

A candidate datastore that can only accept one edit and then automatically
commit is not useful.
I agree RESTCONF should be removed from this draft.

>
>
> Robert.
>
> co-author, privcand
>

Andy

> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>