Mohamed Boucadair has entered the following ballot position for draft-ietf-netmod-system-config-18: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Qiufang, Qin, and Chong, Thank you for the effort put into this specification. Also, thanks to Luis Contreras Murillo for the OPSDIR review and the authors for engaging and implementing changes in -18. I see Luis has some follow-up few suggestions, though. Please find below some few points for DISCUSSion: # Design approach RFC 8342 has the following: dynamic | +-------- learned configuration configuration | +-------- system configuration datastores -----+ | +-------- default configuration | | | v v v +---------------+ | <operational> | <-- system state | (ct + cf, ro) | +---------------+ A design approach that would not impact other datastores is to expand the “system configuration” branch above and replace it with <system>. That would be also consistent with the hierarchy of origin identity defined in RFC 8342: The values are YANG identities. The following identities are defined: o origin: abstract base identity from which the other origin identities are derived. o intended: represents configuration provided by <intended>. ... o system: represents configuration provided by the system itself. Examples of system configuration include applied configuration for an always-existing loopback interface, or interface configuration that is auto-created due to the hardware currently present in the device. ## Is there any reason why that approach is not followed compared to grafting <system> to <intended> as in the current version of the draft? ## Note that with the current design, there are parts of RFC 8342 that needs “tweaking” An example is provided below (there are other similar occurrences): RFC 8342: The system will only provide configuration for this interface if there is no data for it in <intended>. When no configuration for "lo0" appears in <intended>, <operational> will show the system-provided data: <interfaces xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin" or:origin="or:intended"> <interface or:origin="or:system"> <name>lo0</name> <ip-address>127.0.0.1</ip-address> <ip-address>::1</ip-address> </interface> </interfaces> # Origin metadata annotation is normative CURRENT: * Origin: This document does not define any new origin identity. The "system" identity of origin metadata annotation [RFC7952] is used to indicate the origin of a data item provided by the system. This is needed to tag system ds. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Desire CURRENT: However, there is a desire to enable a server to better expose the system configuration, regardless of whether it is in use. Desire of whom? # Root CURRENT: * YANG nodes: all "config true" data nodes up to the root of the tree, generated by the system. This seems to assume one single data tree. Is that intended? If not, I think that it is accurate to use the following: NEW: * YANG nodes: all "config true" data nodes up to the root of a data tree, generated by the system. # It is weird to reason about modification for read-only ds OLD: 6.3. Modifying (Overriding) System Configuration NEW: 6.3. Overriding System Configuration # IANA template for registration OLD: This document registers one YANG module in the 'YANG Module Names' registry, defined in [RFC6020]. NEW: IANA is requested to register the following YANG module in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group. # Examples are not normative CURRENT: The updates of system configuration may be obtained through YANG notifications (e.g., on- change notification) [RFC8639][RFC8641]. [RFC8639] and [RFC8641] are listed as normative, while these should not. Please fix that. # Nits ## Split long sentences + proper RFC citation CURRENT: This document updates RFC 8342 to define a configuration datastore called "system" to hold system configuration (Section 3), it also redefines the term "conventional configuration datastore" from [RFC8342] to add "system" to the list of conventional configuration datastores. or CURRENT: The "intended" identity of origin value defined in [RFC8342] represents the origin of configuration provided by <intended>, this document updates its definition as the origin source of configuration explicitly provided by clients, and allows a subset of configuration in <intended> that flows from <system> yet is not configured or overridden explicitly in <running> to use "system" as its origin value. Cheers, Med _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
