Dear Bing, Thank you very much for your detailed review and many kind words. I have gone through all your review comments below, in most cases proposing new verbiage, in some asking further questions. My comments marked are [JANL]. > Reviewer: Bing Liu > Review result: Has Nits > > Hi Dear author, I'm assigned by the OPS Dir to review > draft-ietf-netconf-transaction-id-07. > > General status: Ready with nits > This document is a high-quality delivery, with clear structure, good > readability, and plenty of examples. It was a pleasure to learn the described > new mechanisms. > > I’ll categorize my comments into “Clarification issues” and “Nits”. The former > might not necessarily be real issues, but elaborating a bit more might help the > audience to more clearly understand the content. > > I. Clarification issues > > #1 Section 3.2 > “Regardless of whether a server declares the Versioned Nodes or not, 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 (a.k.a. > "license") installations or removals.“ > > It means that the txid does not support a normal node transitioning to a > Versioned Node, or verse visa dynamically. It might be good to add a couple of > sentences to explain why it has such limitation, e.g., maybe there is no > requirement in practice, or there might be potential requirement but such > capability requires more sophisticated design that would need another work to > address it. [JANL] Thank you. I propose adding the following to the section 3.2 paragraph quoted above. Do you think that would clarify the situation? """ If the set of Versioned Nodes was allowed to change while a client was connected, the client would no longer be able to reason about the change, since the effective txid of some nodes would sometimes change even when no configuration change has taken place. """ > #2 Section 3.3-3.11 > Section 3.1 lists 5 sample use cases, which are all addressed in sections > 3.4-3.11, along with some other operations such as candidate datastore > transactions and dependencies within transactions etc. The contents are all > good but the sections organization seems like a mixture of use cases and > general mechanisms (or maybe considered as additional use cases than the 5 > ones?). So maybe in Section 3.1 there could a little bit more explanation. [JANL] Good point. I propose updating the last few lines and adding the following text to the end of section 3.1: """ Subscribe to configuration changes with txid return: When a client subscribes to configuration change updates through YANG-Push, it may be interested to also learn the updated txid metadata for the changed data trees, and recognize the YANG-Push echo of its own changes. Compare datastores: When a client compares datastores, it may be interested to get the latest txid values of the nodes being compared. This chapter will also provide some details about how to handle the (or a) candidate datastore, dependencies within a transaction, and txid handling in a few other NETCONF operations (e.g. copy-config). """ > #3 Section 3.6.2 “Txid History Size Consideration” > This section raised an valid issue that some operations would rely on the > server to have a long history of the txid. However, it doesn’t really discuss > the size consideration, neither from time perspective nor data amount > perspective. I think the size issue is important especially for the server. > Some rough guidance should be beneficial for the audience. [JANL] I tried very hard to stay away from concrete recommendations :-), but I guess you are right that some guidance should be given. I propose the following to be added to the end of section "3.6.2 Txid History Size Consideration": """ Choosing a Txid History size greater than zero in a server is an optimization allowing clients to be less explicit, saving both on communications and processing. Servers implementing a Txid Mechanism using txid values with a natural order (e.g. strictly increasing integers or timestamps) may be able to implement an infinite history very easily. Other schemes might need to store recently used txids in a database. It is RECOMMENDED that server implementors that implement Txid History at all choose a Txid History size that is at least large enough to hold twice as many txids as this type of server normally experiences between the typical connection interval by clients, and not less than 100. In a server near the core of a network, the number of transactions would often be high, but the connection interval by clients typically short. Servers closer to the edge might see fewer transactions, but also be visited by clients less often. """ > #4 Section 4 > “Servers implementing this specification MUST support the etag attribute txid > mechanism and MAY support the last-modified attribute txid mechanism.” As > specified in Section 4.1, etag value are strings chosen freely, so this MUST > feature seems to be unclear on how a specific client implementation should be? > Comparing to etag, the last-modified attribute seems to indicating a concrete > implementation (e.g. the time stamp) [JANL] An implementor would have to abide by the behaviors described in chapter 3 regardless of Txid Mechanism, and section 4.1 is also not without requirements for the implementors of the Etag Txid Mechanism, so even if the exact format of the Etag string is up to the implementors, I don't understand why that would be a problem. Could you elaborate on what sort of interoperability issues you have in mind? I have refrained from detailing the exact Etag string format and the basis for its computation because there are a number of viable implementations, each with their strengths and weaknesses. E.g. a strictly increasing integer (dead simple to implement and use), a cryptographic hash (Merkle tree) over the subtree (desirable in certain high security devices or crypto applications), timestamps (that are not exactly following the Last-Modified Txid Mechanism, e.g. with higher resolution timestamps), ... and probably other ideas. > #5 Section 4 > “If a client uses more than one txid mechanism, such as both etag and > last-modified in a particular message to a server, or particular commit, the > result is undefined.” Does this mean that the result is up to server’s specific > implementation? I’m not very sure it is good or bad to give this bit freedom to > the vendors. This reminds me of the M/O bit definition in the IPv6 RA messages, > M indicates there is DHCPv6 service available, O means there is other > configuration other than IP addresses available. But how a host should response > is not defined, then we observed quite distinct behaviors among > Windows/Linux/MACOS. For some administers, this kind of uncertainty might be a > problem. [JANL] It's a terrible idea for a client to use more than Txid Mechanism in a single request. The alternative to leaving such use as undefined is to say that servers MUST reject the request. I didn't want to go there, as that would add a requirement on the server implementor for a stupid corner case. If you still think this is preferable, I will change the undefined behavior above to server MUST reject. Makes sense? > #6 Section 4.1 > “The etag attribute values are opaque strings chosen freely.” > Should the etag value required to explicitly indicating a sequence? E.g., for > numbers, bigger ones indicate newer txids, but strings not necessarily have > this feature. [JANL] Server implementors that wish to use a strictly increasing integer as the server Etag txid value are free to do so. I expect that will be common choice. As I described in my comment to #4 and #3 above, however, requiring the Etag values to have a natural order is not a reasonable requirement for some applications. > II. Nits > - In Section 3, There are numerous abbreviations such as “acl” and “dscp” in > lowercase format in the formal texts, might be good to change them into capital > letters. [JANL] I should probably clarify that I am referring to the names of the elements in a YANG module, and they are all lower case. I'm not referring to the underlying ACL etc concepts. How about adding this paragraph to the end of section "1.1 How to Read this Document"? """ The examples found throughout this document are referencing acls, aces, dscp and many other related names defined in YANG modules. Interested readers can find definitions of the relevant YANG structures in RFC8519. For the purposes of understanding this document, going there is entirely optional. """ - Section 3.4: “Txid values sent by a client are refered to as > c-txid.” s/refered/referred/ - Section 3.6: “the client might issues a > get-config.” s/issues/issue/ - Section 3.10: “A client issuing a YANG-Push > establish-subscription or modify-subscription request or configures a YANG-Push > subscription”: s/configures/configuring/ - Section 4.3: “configuration change > subsription updates” s/subsription/subscription/ - Section 4.3: “may still > supercede the txid value” s/supercede/supersede/ - Section 6.1: “with the > additonal condition” s/additional/additional/ - Section 7.1: “not acessible by > the client” s/acessible/accessible/ - Section 8.1: “This document requets IANA” > s/requets/requests/ - Section 9.6: “to determine the sequnce of transactions” > s/sequnce/sequence/ [JANL] Thank you, I have fixed all these now :-) Excellent review questions. Looking forward to your comments to my proposed edits and questions back to you. Best Regards, /Jan -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
