[netconf] Re: draft-ietf-netconf-transaction-id-05

[Reshad Rahman <[e-mail]>]

 Hi Jan,
Thanks for the prompt response. Please see below.

    On Monday, July 22, 2024 at 03:14:36 AM PDT, Jan Lindblad (jlindbla) <[e-mail]> wrote:  
 
 
Reshad, 
 
  
 
Thanks for the review, much appreciated! Great comments and suggestions.
 
Comments [janl] inline.
 
  
 
  
 
From: Reshad Rahman <[e-mail]>
Date: Friday, 19 July 2024 at 22:02
To: [e-mail] <[e-mail]>, NETCONF WG <[e-mail]>
Subject: draft-ietf-netconf-transaction-id-05
 
Hi Jan,
 
  
 
Some basic questions on this document (apologies, I haven't followed recent discussions/changes). 
 
  
 
Very well-written and clear!
 
  
 
[janl] Thank you, good to hear :-)
 
  
 
In the following paragraph in section 3.3, why use strings as opposed to monotonically increasing integers as in the example?
 
  
    In principle, txid values are opaque strings that uniquely identify a    particular configuration state.  Servers are expected to know which    txid values it has used in the recent past, and in which order they    were assigned to configuration change transactions.  This information    is known as the server's Txid History.    [janl] As server implementor, you may of course decide to use monotonically increasing integers if that makes sense to you. There are a couple of use cases I have in mind, where that is not ideal, however.    + A server that is a distributed system (e.g. controller or orchestrator) may prefer not to have a central integer that all subsystems have to coordinate around    + In certain environments, it may be advantageous for servers to use cryptographic hashes over the subtrees as the txid mechanism. We have worked hard with the text not to preclude that.
<RR> Ack, makes sense.    In the following paragraph in section 3.3, any consideration to having that number either configurable or retrievable from oper state?          How many historical txid values to track is up to each server    implementor to decide, and a server MAY decide not to store any    historical txid values at all.  The more txid values in the server's    Txid History, the more efficient the client synchronization may be,    as described in the coming sections.    [janl] Good question. I certainly thought about that. In the end I wasn’t able to come up with any credible use case for what a client would do with this information (or control). So with Occam as my advisor, I decided to leave it out. If you have some use case in mind where this would be useful, I’d be very interested to hear.
<RR> For config, I can't think of any useful use-case. Control of resources on the server seems to be a "far-fetched" use-case.For oper (for the client to know what the server supports for historical values), I was wondering if this could help clients craft their requests to increase the chance the request from the client would succeed. It's probably fine to do without and add it in the future if needed.    
Section 3 nit: implememnting -> implementing
 
  
 
[janl] Thanks, fixed!


 
Section 6.1, 2 mechanisms are mentioned in the feature below, 1 is a MUST and the other MAY.
 
How is support for the last-modified txid mechanism indicated?
 



      feature last-modified {        description "Servers implementing this module MUST support the          etag txid mechanism.  Servers MAY also support the          last-modified txid mechanism.  Support is shown by announcing          this feature.";      } 
  
 
[janl] Here we are relying on the YANG built-in feature mechanism, which is already described in 6020 and 7950. Since this is a YANG 1.1 module, this means supported features are listed in YANG Library.

<RR>  I understand that :-) I misread the description (I thought this feature was for 2 mechanisms). All good.


 
Section 6.1, for etag-t, should there be a reference? Also, an explanation for what the special meaning of '?', '!' and '=' are, e.g a reference to last-modified-t?
 
  
 [janl] Thanks, good suggestion. Fixed!<RR> Thanks. For etag, should there be a reference to 2.3 of RFC7232?
Regards,Reshad.




Section 6.1 nit: should be "relative to the running datastore".
                relative the running datastore, but not yet received    
[janl] Thanks, fixed!
    Fixes will be released in the -06 version of the document.    Best Regards, /jan