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. #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. #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. #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) #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. #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. 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. - 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/ -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
