Re: [netconf] RESTCONF support in private candidates draft

[Andy Bierman <[e-mail]>]

Hi,

On Sat, Mar 16, 2024 at 11:21 PM Robert Wills (rowills) <[e-mail]>
wrote:

> Kent, Andy,
>
>
>
> Thank you both for taking the time to provide feedback.
>
>
>
> In draft-ietf-netconf-privcand-02, which was recently published, I have
> attempted to incorporate this feedback.
>
>
>
> Summarising:
>
>    1. With RESTCONF, the private candidate is tied to the client, using
>    the client identity as described in RFC 8040 Section 2.5
>    2. When the private candidate datastore is explicitly referenced in
>    the request, then edits are made to the client’s private candidate and are
>    NOT committed. The client must execute an ietf-netconf:commit operation to
>    commit them.
>    3. When the private candidate datastore is not explicitly referenced
>    in the request, changes are made in a private candidate and the private
>    candidate is instantly committed.
>
>
>

I need to study the details more, but I prefer:

-  a YANG-based solution, meaning the entire management feature is defined
in YANG.
   That way, different protocols that map YANG to operations can be used
without any special
   standards or special code (on the client or server).  This allows NC,
RC, and CC to provide
   consistent behavior, and do it automatically with minimal development
costs.

-   a solution that is not tied to sessions at all
    - client must create and later delete a private candidate (with
configurable timeout before auto-deleted)
    - many tools use multiple sessions to get edits into <candidate>.   The
current auto-clean only applies
      if <candidate> is locked.

-   must be one mandatory-to-implement solution, not several optional
server variants
    - OK to add-on optional functionality using YANG features

-  must not get in the way of implementations the way NETCONF
'error-option' did.
   Any client control over behavior must be optional with YANG features

I am not sure how the draft handles auto-deletions.
  - explicit edit causes existing nodes in a YANG choice to be replaced
with a new case
  - explicit edit causes when-stmt to change to 'false' for other data nodes



Andy


The bulk of the changes are in Section 4.4.3, with small changes elsewhere
> to make it hang together.
>
>
>
> Elaborating on each of the points above:
>
>
>
> (1) Private candidate is tied to the client
>
> On re-reading the draft, I think it should be more explicit that it’s tied
> to the client identity from 8040. I will make this change in -03.
>
>
>
> (2) Privcand datastore explicitly referenced in the request
>
> Kent and Andy, you both agree that a candidate datastore that’s instantly
> committed is not useful. Hopefully what I’ve now written (in Section
> 4.4.3.2) provides something more useful in implementations that support
> privcand.
>
>
>
> (3) Privcand datastore not explicitly referenced
>
> In this case, the private candidate datastore IS automatically committed.
> This is for backwards compatibility with clients that aren’t aware of
> private candidates: they are expecting their changes to be committed. Kent,
> I hope this captures the spirit of what you were after?
>
>
>
> Further comments are very welcome.
>
>
>
> Many thanks,
>
> Robert.
>
>
>
> *From: *Andy Bierman <[e-mail]>
> *Date: *Thursday, 8 February 2024 at 22:02
> *To: *Kent Watsen <[e-mail]>
> *Cc: *"Robert Wills (rowills)" <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Subject: *Re: [netconf] RESTCONF support in private candidates draft
>
>
>
>
>
>
>
> 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
>
>
>
>
>
>
>
>