Bing, Thank you very much for your detailed review and kind words! I will come back with proposed language updates shortly. Best Regards, /Jan On Sunday, January 19th, 2025 at 18:47, Bing Liu via Datatracker <noreply@xxxxxxxx> wrote: > 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/ > > > _______________________________________________ > netconf mailing list -- netconf@xxxxxxxx > To unsubscribe send an email to netconf-leave@xxxxxxxx -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx