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

["Jan Lindblad (jlindbla)" <[e-mail]>]

Qiufang, NETCONF WG,

Thank you very much for the extensive review, much appreciated! I apologize for the slow response; Sweden pretty much shuts down during July :-)

My comments inline below as [janl].

From: maqiufang (A) <maqiufang1=[e-mail]>
Date: Friday, 21 June 2024 at 08:01
To: [e-mail] <[e-mail]>
Subject: [netconf] Comments on draft-ietf-netconf-transaction-id-05
Hi, all,

Following are some comments on the latest version of transaction-id draft, I have reviewed some previous version of this draft before, but this version I feel it’s more complete and well thought-out.

General:

This draft introduces txid mechanism to NETCONF protocol, YANG-push, and NMDA-diff compare operation, but I am unsure if this draft should formally update RFCs 6241, 8639/8641 and 9144, given extensions being made to these RFCs.


[janl] IMHO the txid draft just builds on those documents without changing them, so I would think there is no need to declare them updated. But I’m far from an IETF document expert, so if you or someone says that should be added, I will.



I wonder if the txid mechanism would be applicable to system configuration, I assume yes? and I think there is some value here to allow the client to discover if system configuration has been changed, and the server can similarly prune the retrieval response of <system> to save time and energy. But of course this won’t involve conditional configuration update for <system> which is read-only.


[janl] I agree. I think that would make sense.

Comments based on specific sections:



Section 2, I think it might be good if the etag and last-modified could be mentioned in the “Transaction-id Mechanism” term as two different mechanisms of txid, both should be mentioned earlier in the document.


[janl] Thanks for the suggestion, I modified+added language like this in the Definitions section. Does that resolve your comment?

Transaction-id Mechanism:
: A protocol implementation that fulfills the principles described in
the first part, [NETCONF Txid Extension](#netconf-txid-extension), of
this document.  See also Etag and Last-Modified.

Etag:
: One protocol mechanism that conforms to the definitions in the
[NETCONF Txid Extension](#netconf-txid-extension) section in this
document.  Also the name of the XML attribute that this mechanism
uses in the NETCONF stream, and the message header used in RESTCONF.

Last-Modified:
: Another protocol mechanism that conforms to the definitions in the
[NETCONF Txid Extension](#netconf-txid-extension) section in this
document.  Also the name of the XML attribute that this mechanism
uses in the NETCONF stream, and the message header used in RESTCONF.



Section3.2 states that:

All servers implementing a txid mechanism MUST maintain a top level server side txid meta data value for each configuration datastore supported by the server.

This seem to imply that the server doesn’t have to maintain the txid for state datastore, i.e., <operational>, even if it contains config true nodes. Is this intentional? Because I think it might also be useful sometimes for clients to track if configuration in <operational> has changed, even config false nodes in <operational> are out of scope.


[janl] Interesting question. I agree it could provide some value, but I suspect it may also complicate matters for some implementations. Let’s see if others also find txid on <operational> valuable.



Section3.3 shows an example as figure 1, at first I don’t understand why R8 and R9 are the most recent changes until I realize that the server chooses the same txid values (i.e., 5152) for nodes being updated and their ancestors in the example, is this something that will always happen? Or the server is allowed to choose txid values for each versioned node independently? It doesn’t seem to be specified in sec.3.2.



[janl] It is up to the implementation to choose txid values for each node. The same value could be used for all nodes in a given transaction, or all different values, or something in between. I tried to clarify that using the same value in the examples is for readability purposes like below. Would that be enough, do you think?


> The call flow examples in this document use a 4-digit,
monotonously increasing integer as txid.  The same txid value
is also used for all changed nodes in a given transaction.
These conventions of the examples are convenient and enhances
readability of the examples, but do not necessarily
reflect a typical implementation.



Section3.4 has a table that describes how the server processes the configuration with its txid sent by the client, and in case 3, the node is not a versioned node, then it will inherit the txid value of its closest ancestor node, does this mean that this node would become a versioned node? Note sec3.2 states that: the set of Versioned Nodes in the server's YANG tree MUST remain constant, except at system redefining events, such as software upgrades or entitlement installations or removals.


[janl] I prefer to use the “versioned node” concept only for nodes that keep their own transaction id value, and not the ones inheriting it. The intended meaning is that nodes that are not “versioned nodes” would for the purposes of evaluating the txid processing rules be considered to have the same txid as their closest ancestor that is a “versioned node”. Because you are asking I realize this is not entirely clear. Do you think the following text for case 3 clarifies the situation?

In this case, the current node MUST, for the purposes of these rules, temporarily inherit the server's s-txid value of the closest ancestor that is a Versioned Node (has a server side s-txid value).  The datastore root is always a Versioned Node.  Processing of the current node continues according to the rules below.


Again, is this based on the premise that the server uses the same txid value for both changed versioned node and all of its ancestor nodes? If yes, this should be specified in the txid principles section.

[janl] No, that is not the premise.

Section3.4 Figure 3, the server returns 6614 as s-txid value, but the text describes 7770 as the most recent used s-txid.

[janl] I’m sorry if this example causes confusion. I intended 7770 to be a transaction that is unrelated to the acls subtree. I updated the text under the figure as follows. Does that clarify the intent?

Out of band change detected.  Client sends get-config
request with known txid values.  Server provides updates only where
changes have happened.  (Txid 7770 does not appear in this subtree,
so that transaction must relate to some changes elsewhere.)

Section 3.5 defines how txid is used for <candidate>, I think it’s quite interesting. I wonder how this section is related to sections 3.3 and 3.4. Are sections 3.3 and 3.4 applicable to datastores other than <candidate>?

[janl] I definitely intended 3.3 and 3.4 to apply to transactions towards <running> as well.

Section 3.5 states that: “If a client makes further changes in the candidate datastore, the s-txid value MAY change. ”  But I feel it contradicts the statement in sec.3.1 that “a server MUST update the txid value for any nodes that change as a result of a configuration change”.

[janl] Ah, I see how you read that MAY. The intent is to say that if the client makes further changes, any txid that the client has read from the candidate MAY no longer apply. It MUST of course be different from the previous txid value for this leaf, but the point it MAY also be different than the value just reported for the candidate. Is this better?

- If the txid-unknown value is not returned, the server MUST return
  the s-txid value the node will have after commit, assuming the client
  makes no further changes of the candidate datastore.  If a client
  makes further changes in the candidate datastore, the s-txid value
  MAY change again, i.e. the server is not required to stick with the
  s-txid value just returned.


Section 3.5 also reminds me some other cases where same nodes present in different datastores. E.g., what if the clients copy configuration from <system> into <running>? Will the server use the same txid for nodes in <running> as maintained in <system>?


[janl] I have to admit I have not given this much thought. It seems to me that it would be useful to allow servers to use the same txid for the copied nodes, but not require it. If you agree with this interpretation, maybe no new text is even needed?


Section3.6, what if the client indicates the txid value for a non-versioned nodes? Will the server handles in the way same as sec.3.4? or will the server report an error or silently ignore it?


[janl] My opinion is that the 3.4 rules should apply.



Section3.6.1, I am unsure if we would like to define a new error-tag, e.g., mismatch-txid.  The operation-failed may be too generic to be useful.


[janl] I understand. I refrained from this because of the compatibility implications, and the complications around updating base documents like 6241 etc. If several people think this is important, we can do that of course.



My reading to section 3.7 is that the client won’t carry c-txid in the commit operation (including the txid for the <candidate> ds), instead the server records the c-txid carried in the last recent <edit-config> operation, right? If the server returns a txid-unknown value (e.g. "!"), how would the client specify the txid for a subsequent <edit-config>?


[janl] That’s right, the server tracks the (latest) txid:s sent by the client, but does not apply the txid logic until commit time. If a client reads (some part of) the candidate configuration, it might get the txid-unknown value (e.g. “!”). That just means the candidate value is different than running. The client can still provide any txid value from the txid history if it wants to make the edit-config conditional on knowledge the client already has. The “!” represents a value from the future, so could never be in the history anyway.

Section 3.7 starts with the following sentence:

When using the (or a) Candidate datastore, the txid validation
happens at commit time, rather than at individual edit-config or
edit-data operations.


Do you think we should extend this text to clarify when the c-txid values are evaluated?


Section3.10, it might be worth mentioning that we also support txid mechanism for configured subscription by augmenting the subscriptions container.


[janl] Thanks, good point. How about this:

A client issuing a YANG-Push establish-subscription or
modify-subscription request or configures a YANG-Push subscription
towards a server that supports
ietf-netconf-txid-yang-push.yang MAY request that the server
provides updated txid values in YANG-Push on-change subscription
updates.



Section4.3.1 has the duplicate contents as Section3.5.


[janl] I have tried hard to minimize the duplication, but I haven’t been able to remove it completely. Chapter 3 talks about requirements that ALL current and future txid mechanisms must abide by. Chapter 4 talks about how two specific (etag and last-modified) txid mechanisms work. Since they have to follow the general rules, I was not able to write text that was both readable and had no duplication with chapter 3. If you have ideas of how to improve the chapter 4 text to reduce duplication and keep reasonable readability, I’d be grateful.



Section5.1.1 missing source parameter in the <get-config> RPC operation.


[janl] Ah, thanks. Good catch! Fixed.



Section6.1 YANG module, the description of extension versioned-node is confusing to me, the second paragraph states "Servers are not required to use this statement to declare which nodes are versioned nodes." but isn’t it defined to declare which nodes are versioned nodes? Did I misunderstand something?


[janl] I intended to say that servers MAY use that statement to declare which nodes are versioned nodes, but such declarations are entirely optional. Some servers will use it, some won’t. Some might use it for some of its nodes, while not for others.



Section 6.1 yang module the with-etag and with-last-modified are defined as boolean type without default statements, I think it should be default false. But it might be even better to be defined as empty type?

[janl] Thanks. I started to make this change, but then I realized why I did it this way, long ago. One of the places where the with-etag leaf shows up is in YP modify-subscription. In that case, the client may use all three states of type Boolean, i.e. true (use etag), false (do not use etag), and no-value (do not change the current with-etag value). We could of course use a type Boolean without a default only for that case, but I preferred to keep the surprise factor low and use the same type, values and default value for all occurrences of with-etag. Let me know what you think we should do about that.

Nits:


Section 3, s/implememnting/implementing/

Section 3.1 ,s/mecahnisms /mechanisms/

Section 3.1:
OLD: …it  may be interested to also learn the the updated txid meta data for the changed data trees.

NEW:… it  may be interested to also learn the updated txid meta data for the changed data trees. (remove “the”)

Section3.4. s/obviosuly/obviously/

Section3.5 s/canidate/candidate/

Section4 s/patricular/particular/


[janl] Thanks, updated!

Many thanks for the review! Many very good points 🙏

Best Regards,
/jan