Re: [netconf] RESTCONF support in private candidates draft

[Andy Bierman <[e-mail]>]

On Thu, Feb 8, 2024 at 1:30 PM Kent Watsen <[e-mail]> wrote:

> Robert, Andy, et. al.,
>
>
> On Feb 6, 2024, at 12:35 PM, Andy Bierman <[e-mail]> wrote:
>
>
>
> On Mon, Feb 5, 2024 at 4:32 AM Robert Wills (rowills) <rowills=
> [e-mail]> 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)
>>
> It would be better for this draft to define nothing than to define it this
> way.
> But all is not lost.  This is an opportunity to fix it.
>
> 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").
>>
> RFC 8040 should’ve just said to use the operations supported by the
> various NETCONF’s capabilities under the {+restconf}/operations resource.
>
>
I disagree.
RESTCONF does not have sessions.
NETCONF :candidate is session-specific.
No changes to the existing URI s (e.g. /restconf/data) should be made.



> 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).
>>
> As a RESTCONF expert, I will help.
>
> RFC 8040 only says what happens when certain datastores are supported.
> It says nothing about what happens when a datastore called
> “private-candidate” is implemented.  Thus this draft gets to define that
> behavior, and it doesn’t have to match RFC 8040’s “support” for :candidate.
>
>
As long as new mechanisms and URIs are used, this should be OK.

IMO RESTCONF does not really need its own way of doing everything, because
the /restconf/operations interface
is very easy to use.

Andy

This draft can state:
>
> - when "“private-candidate” is implemented:
> - edits accumulate in the client-specific candidate datastore
> - the client-specific candidate datastore can be committed
>   using  {+restconf}/operations/ietf-netconf:commit
> - the client-specific candidate datastore can be discarded
>   using {+restconf}/operations/ietf-netconf:discard-changes
>
> - if :validate is also implemented:
> - the client-specific candidate datastore can be validated
>   using {+restconf}/operations/ietf-netconf:validate
>
> - if :confirmed-commit is also implemented:
> - the {+restconf}/operations/ietf-netconf:commit operation
>   can take the “confirmed” attribute
> - the commit can be canceled using
>   {+restconf}/operations/ietf-netconf:cancel-commit
>
> Note:  I am not trying at all to introduce to RESTCONF an equivalency to
> NETCONF’s <target> attribute.  I’m perfectly okay with the following
> auto-selection:
>
> if :running implemented:
> - RC-edits go to <running> and are auto-committed
> - this is from RFC 8040 and is fine (matches :writable-running behavior)
>
> else if :candidate is implemented:
> - RC-edits go to <candidate> and are auto-committed
> - this is from RFC 8040 and is not good (explained above)
> - but let’s hope that :candidate becomes a thing of the
>   past in an NBC-update to RESTCONF
>
> else if :private-candidate is implemented:
> - see behavior described above.
> - but, to work, this draft needs to say that neither
>   :running nor :candidate can be implemented…
> - this would be goodness
>
> 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.
>>
> A common strategy is to have one “place” where protocol-independent
> behavior is defined, and then a “place” for each protocol, where
> protocol-specific syntax is defined.   The only question is if the *places*
> are sections in a draft, or separate drafts (e.g., in the list-pagination
> work).
>
> IMO, if you want to isolate RESTCONF, then NETCONF should be also be
> isolated (i.e.: there would be 3 drafts).  Good reasons for doing this are
> 1) because each is a heavy topic, perhaps too big for all be in one draft)
> and 2) because independent documents make for better references.
>
> Thoughts and comments are very welcome.
>>
> Thank you for sending out this message.
>
>
> From Andy:
>
> A candidate datastore that can only accept one edit and then automatically
> commit is not useful.
>
>
> I agree that it would not be useful.
> It was also not useful when RFC 8040 defined it.
>
>
> Also from Andy:
>
> I agree RESTCONF should be removed from this draft.
>
>
> This is too important to not support in RESTCONF (and CORECONF, I assume).
>
>
> Kent // contributor
>
>
>
>