[netconf] RESTCONF support in private candidates draft

["Robert Wills (rowills)" <[e-mail]>]

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.

Robert.
co-author, privcand