Hi Authors, The document addresses a genuine gap: servers have long silently rejected modification of system-provided configuration without any machine-readable way to communicate immutability to clients ahead of time. The metadata annotation approach is appropriate, and the examples are helpful. The shepherd (thanks Kent Watsen) has done a thorough job, and the YANG Doctors (thanks Per) issues from the -06 early review appear to have been resolved in subsequent versions.
That said, I have two MAJOR and several MINOR comments that need to be addressed before I can approve publication. MAJOR: Section 3, paragraph 0 > While the immutable flag applies to all configuration nodes, its > value true can only be used for system configuration. The phrase "can only be used for" sounds normative, but has no RFC 2119 language. This should use MUST NOT. For example, "its value true MUST NOT be set to true for configuration data that is not system configuration." Without normative language, this is just advice that implementations may ignore. Section 3, paragraph 0 > The immutable flag is only visible in read-only datastores (i.e., > <system> [I-D.ietf-netmod-system-config], <intended>, and > <operational>) when a "with-immutability" parameter is carried > (Section 4.2), however this only serves as descriptive information > about the instance node itself, but has no effect on the handling of > the read-only datastore. If the immutable flag is requested to be > returned for an invalid datastore, then the server MUST return an > <rpc-error> element with an <error-tag> value of "invalid-value". The last sentence is NETCONF-specific (<rpc-error>). For RESTCONF, Section 4.2.2 separately says the server returns "400 Bad Request" when the parameter has an unexpected value, but that addresses a different case (malformed parameter value, not wrong datastore). There is no explicit statement about the RESTCONF error response when with-immutability is used against a read-write datastore. Furthermore, there is a tension between this normative text and the YANG module itself: the with-immutability leaf has a when condition restricting it to <system>, <intended>, or <operational>. When the when condition is false, the leaf conceptually does not exist in the schema for that context. Servers might return "unknown-element" rather than "invalid-value." The normative requirement in Section 3 conflicts with what the YANG when semantics imply. Please reconcile these two mechanisms and provide consistent error behavior specification for both NETCONF and RESTCONF. MINOR: Section 1, paragraph 5 > This document defines a way to formally document the existing > behavior, implemented by servers in production, on the immutability > of some system-provided nodes, using a YANG metadata annotation > [RFC7952] called "immutable" to flag which nodes are immutable. This > document does not regulate server behaviors. That said, it is > expected that a server will return an error with an error-tag > containing "invalid-value" when immutability is attempted to be > violated. The passive construction "attempted to be violated" is awkward. Suggest: "when a client attempts to modify an immutable node." Section 4.1, paragraph 1 > A node that is annotated as immutable cannot be changed via > configuring a different value in read-write configuration datastores > (e.g., <running>), nor is there any way to delete the node from the > combined configuration in the intended datastore (as described in > Section 4 of [I-D.ietf-netmod-system-config]). The node MAY be > explicitly configured by a client in <running> with the same value > and that configuration in <running> may subsequently be removed, but > neither of these edits will change the configuration in <intended> > (if implemented) on the device. The statement "the combined configuration in the intended datastore" without defining what "combined" means. A reader unfamiliar with the system-config draft won't know this refers to the merge of <running> and <system> into <intended>. Add a brief explanation or a cross-reference to the system-config draft definition. Section 6, paragraph 0 > Immutability is a conceptual operational state value that is > recursively applied to descendants, which may reset the immutability > state as needed, thereby affecting their descendants. There is no > limit to the number of times the immutability state may change in a > data tree. This section describes immutability as "a conceptual operational state value." This phrasing conflates metadata about configuration with operational state data, which are distinct concepts in NMDA. Suggest: "Immutability is a property of a configuration data node instance, conveyed as metadata." Section 8, paragraph 0 > The server rejects an operation request due to immutability when it > tries to perform the operation on the request data. It happens after > any access control processing, if the Network Configuration Access > Control Model (NACM) [RFC8341] is implemented on a server. For > example, if an operation requests to override an immutable > configuration data, but the server checks the user is not authorized > to perform the requested access operation on the request data, the > request is rejected with an "access-denied" error. This section says the server rejects due to immutability "after any access control processing." This ordering has security implications (it avoids leaking immutability information to unauthorized users). However, the text is descriptive. If this ordering is intentional as a security property, it should be SHOULD or MUST. If it's implementation-defined, say so. Section 9, paragraph 9 > description > "If this parameter is present, the server returns the > 'immutable' annotation for configuration that it > internally thinks immutable."; "internally thinks immutable" is informal. Suggest "for configuration that the server considers immutable." "B.1.", paragraph 3 > <rpc-reply message-id="101" > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > <data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"> > <user-groups xmlns="urn:example:user-group" > xmlns:imma="urn:ietf:params:xml:ns:yang:ietf-immutable-\ > annotation" > imma:immutable="false"> > <group imma:immutable="true"> > <name>administrator</name> > <description imma:immutable="false">administrator group</\ > description> > <access-level>admin</access-level> > <user> > <name>ex-username-1</name> > <password>$5$rounds=10000$mysalt123456789$l4BjA1p/8q.qCYJ.\ > 2pLqjR5mCJf2bP7cLpYWmnC7Hq8</password> > </user> > <user imma:immutable="false"> > <name>ex-username-2</name> > <password>$1$/h1234q$abcdef1234567890abcdef</password> > </user> > <tag>system</tag> > <tag>non-editable</tag> > </group> > <group imma:immutable="false"> > <name>power-users</name> > <description>Power user group</description> > <access-level>power</access-level> > <user> > <name>ex-username-3</name> > <password>$1$/h4567q$abcdef2345678901abcdef</password> > </user> > <tag>system</tag> > <tag>editable</tag> > </group> > </user-groups> > </data> > </rpc-reply> The document allows servers to return immutable="false" explicitly (the example above does so for several nodes). Section 6 says servers "may suppress the annotation if it is inherited from its parent node or uses the default value." However, returning explicit false for a top-level node whose default is already false adds noise with no information value. This and other examples in this Appendix do this Consider either removing these from examples or adding explanatory text about why a server might choose to be explicit even when the value matches the default. Thanks Mahesh Jethanandani [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
