Re: [netconf] I-D Action: draft-ietf-netconf-privcand-01.txt

[Jan Lindblad <[e-mail]>]

Rob, James, WG,

Thanks for the updated privcand draft. As you know, I'm quite interested in this topic and I'm very glad you are continuing the design effort. I had a read through the latest version, and I have some comments. Almost all of them revolve around the conflict detection and resolution, where I feel we still have some work to do before we have something usable.

1) Requirements for legacy servers

In section 4.4.1 there is some language about how servers that do *not* implement the privcand feature should behave:

4.4.1.  Server
...
   If the server has not signalled the :private-candidate capability, or
   otherwise does not support private candidates, the server MUST:

   *  Terminate the session when it receives the :private-candidate
      capability from a client in a <hello> message,

   *  Return an <rpc-error> if a client attempts to interact with the
      NMDA private-candidate configuration datastore.

I don't think this is necessary, nor allowed by the NETCONF protocol principles. You cannot introduce binding behavior for existing servers post-implementation. Many servers out there would probably not immediately terminate a session from a client just because it includes the above mentioned capability in the hello. I don't think outlawing such servers is a good idea.

2) Need a broader conflict definition

Section 4.6.1 proposes a definition of the conflict concept as follows:

4.6.1.  What is a conflict?

   A conflict is when the intent of the NETCONF client may have been
   different had it had a different starting point.  In configuration
   terms, a conflict occurs when the same set of nodes in a
   configuration being altered by one user are changed between the start
   of the configuration preparation (the first <edit-config>/<edit-data>
   operation) and the conclusion of this configuration session
   (terminated by a <commit> operation).

IMHO the above statement is a bit too simplistic. Real world relevant conflicts may arise even when there are no overlapping edits. Let's say one client changes the MTU of an interface while another decides to shut it down. That's a real conflict to me, but with no YANG-leaf overlap between the edits.

You may think it would be horribly complicated to detect conflicts that are non-overlapping, but actually I don't think so. If we would reuse the txid concept lain out in the transaction-id draft, the clients have very fine control over what they consider conflicting changes. There may be other solutions too. My point is that we need a broader definition to handle real world cases.

3) Unclear conflict reporting mechanism

Section 4.6.2 says that conflicts should be detailed by the server. I didn't see any description of how this happens/the format for this. As noted multiple times in the document, this may be hard for servers in the "continuous rebase mode" to do given the way the auto update mechanism is designed. It's hard for me to see how a client could work efficiently in this scenario, and some example scenario would be appreciated.

4.6.2.  Detecting and reporting conflicts
...
   It MUST inform the client of the conflict and SHOULD detail the
   location of the conflict(s).

4) Single conflict resolution mechanism in effect

Section 4.6.3 describes how a client chooses one of several conflict resolution modes. This feels a little clunky to me, as I would like to choose a different resolution mode for different parts of the data tree. I'd be happy to "ignore" changes in most parts of the data tree. In some others (that I "own") I may be interested in the "overwrite", and in particularly sensitive areas or use cases I may opt for some option to abort. There is an option "revert-on-conflict" that might come close, but that one is not available in the "continuous-rebase-mode".

I think the conflict detection and resolution part of the design needs more thought. One way of progressing that I personally find very promising and interesting is to reuse some of the txid-concepts, but of course there may be other viable mechanisms to be found. If you are interested to hear more about how I think the privcand work could be integrated with txid, I'm more than willing to meet and explain my thoughts.

Another observation is that this document now has 2*3=6 different modes to consider when handling conflicts. It's expensive to both implement and test many different modes (not to mention confusion), and this is true both on server and client side. Interoperability gets harder to achieve. If we could reduce the number of different modes in the privcand specification, I think that would be a significant plus.

Best Regards,
/jan


> On 21 Oct 2023, at 01:41, [e-mail] wrote:
> 
> Internet-Draft draft-ietf-netconf-privcand-01.txt is now available. It is a
> work item of the Network Configuration (NETCONF) WG of the IETF.
> 
>   Title:   NETCONF Private Candidates
>   Authors: James Cumming
>            Robert Wills
>   Name:    draft-ietf-netconf-privcand-01.txt
>   Pages:   27
>   Dates:   2023-10-20
> 
> Abstract:
> 
>   This document provides a mechanism to extend the Network
>   Configuration Protocol (NETCONF) and RESTCONF protocol to support
>   multiple clients making configuration changes simultaneously and
>   ensuring that they commit only those changes that they defined.
> 
>   This document addresses two specific aspects: The interaction with a
>   private candidate over the NETCONF and RESTCONF protocols and the
>   methods to identify and resolve conflicts between clients.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-privcand/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-netconf-privcand-01.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-netconf-privcand-01
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>