Dear Authors, In doing the Shepherd writeup, I found some issues.
Thanks, Kent (in document order) 1) nit: s/internally thinks immutable/internally thinks the data is immutable/ 2) For the paragraph: "This document does not apply to the server not having any immutable system configuration. While in some cases immutability may be needed, it also has disadvantages, therefore it SHOULD be avoided wherever possible." a) the first sentence contains a double-negative. Would "This document only applies to servers having system configuration." ? b) what are the "disadvantages"? c) I question if this paragraph is needed at all. 3) Section 1.1: s/input parameter/query parameter/ 4) This is a nit, but Section 3 says: "its value "true" can only be used for system configuration". Technically, the value "true" is encoding-dependent. Whilst true for both XML and JSON, I imagine CBOR uses a binary value. Note, the use of "true" and "false" in Section 9 is okay, since it is a NETCONF/XML-specific If changing here, also consider changing the first sentence in Section 3 (Applicability). In all cases, I think the fix is just to remove the quotes around the true/false strings. 5) Section 3 also says: "An instance has the same immutability if it appears in different datastores, the immutability of configuration data is also protocol and user independent." a) this looks like two sentences. b) assuming the 1st sentence is "An instance has the same immutability if it appears in different datastores", I don't understand if needed (since it's more a "system-config" statement) but, if keeping, then maybe s/instance/instance data/ or s/instance/configuration data/ ??? c) assuming the 2nd sentence is "the immutability of configuration data is also protocol and user independent.", the word "also" can be removed. 6) Section 3 also says: "The immutability of any configuration data, and the value of any immutable configured data node, MUST only change via software upgrade, hardware resources change, or license change." But https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-20#section-6.1 says "The contents of <system> MAY change dynamically under various conditions, such as license change, software upgrade, and system-controlled resources change (see Section 2.2)." There seems to be a mismatch. Since the first paragraph in Section 3 says "While immutable flag applies to all configuration nodes, its value "true" can only be used for system configuration.", maybe this sentence can be removed, deferring to the "system-config" draft to define when system-config can change? 7) In Section 4.1: OLD: The immutable flag which is defined as the metadata annotation takes a boolean value NEW: The "immutable" flag, which is defined as a metadata annotation, takes a boolean value 8) Section 4.2.2 says: "To enable a RESTCONF client to discover if the "with-immutability" query parameter is supported by the server, the following capability URI is defined: urn:ietf:params:restconf:capability:with-immutability:1.0". Shouldn't there be a similar statement in Section 4.2.1? 9) In Section 6: s/for returned child node/for a returned child node/ 10) In Section 7: OLD: which merely mean making immutable nodes visible/invisible in the datastore. NEW: which merely makes immutable nodes visible/invisible in the datastore. or maybe something different, like "Configuring immutable nodes is generally unnecessary, but can be helpful for visibility reasons. The only time an immutable node must be configured is when it is a "key" node to a list element." ??? 13) In Section A1: s/config=false/"config false"/ and s/config=true/"config true"/ (as these are YANG statements) 14) In Section A2: s/config true/"config true"/ 15) In Appendix B, s/prefix "ex-urp"/prefix ex-urp/. Found by testing the file "example-user-group.yang": ``` $ pyang -f yang --keep-comments --yang-line-length 69 example-user-group.yang > tmp && diff example-user-group.yang tmp && rm tmp 4c4 < prefix "ex-urp"; --- > prefix ex-urp; ``` Kent // as Shepherd
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
