[Last-Call] Re: [netconf] Opsdir last call review of draft-ietf-netconf-transaction-id-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux