Thank you for the attention, RFC Ed! Let me go through your comments below.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> [JMC] I do not think we need any additional keywords. What we have in terms of “syslog” and “yang data model” seem descriptive enough to find this. 2) <!--[rfced] We have received guidance from Benoit Claise and the YANG Doctors that "YANG module" and "YANG data model" are preferred. We have updated the text to use these forms. Please review. --> [JMC] Good with this. 3) <!-- [rfced] Some author comments are present in the XML. Please confirm that no updates related to these comments are outstanding. Note that the comments will be deleted prior to publication. --> [JMC] I did not see anything that wasn’t called out elsewhere. 4) <!-- [rfced] What field is "[RFC5424] field" referring to in this sentence? Original: Within each action, a selector is used to filter syslog messages. A selector consists of a list of one or more filters specified by facility-severity pairs, and, if supported via the select-match feature, an optional regular expression pattern match that is performed on the [RFC5424] field. --> [JMC] In this case – and used in other places in the document – the field is the message text. In RFC5424 parlance that is MSG (Section 6.4). 5) <!-- [rfced] This text has been changed from an artwork element to a sourcecode element with type="pseudocode". Please let us know if you prefer to change it to running text (within a <t> element). [JMC] Pseudocode works here. Original: A syslog message is processed if: There is an element of facility-list (F, S) where the message facility matches F and the message severity matches S and/or the message text matches the regex pattern (if it is present) Perhaps: A syslog message is processed if there is an element of facility-list (F, S) where the message facility matches F, the message severity matches S, and/or the message text matches the regex pattern (if it is present). --> 6) <!-- [rfced] FYI, in the YANG tree, this line was followed by a floating question mark, which we moved up to the preceding line. This line exceeds the character limit (69 chars for <sourcecode>) by 3 characters. For updating it, which option do you prefer? Original: | | | {certificate-expiration-notification} ? Current: | | | {certificate-expiration-notification}? Option A (using the "\" line wrapping notation as used in Appendix A.1 and adding the note about line wrapping for formatting only): | | | {certificate-expiration-notificati\ on}? Option B (moving it 3 spaces to the left): | | | {certificate-expiration-notification}? --> [JMC] I think option A is the more consistent choice. 7) <!-- [rfced] We have the following questions regarding the YANG module. a) What do the numbers in parentheses refer to in various descriptions? They seem to refer to the numerical codes in Table 1 of RFC 5424; should a sentence be added so that this is clear to readers? [JMC] Yes, those are the encoded numeric values for the local facilities. Maybe instead of parenthesizing these, each identity can have a second sentence in the description: OLD: … (X). NEW: …. The RFC5424 numerical code is X. [JMC] And alter the reference to point to Section 6.2.1 of 5424. Original: "The facility for local use 0 messages (16)."; b) May we change two instances of "the compare" to "the compare operation" to match previous use? Original: "The compare can be used to specify the comparison operator that should be used to compare the syslog message severity with the specified severity." Perhaps: "The compare operation can be used to specify the comparison operator that should be used to compare the syslog message severity with the specified severity." --> [JMC] Yes to “the compare operation”. That reads considerably better. 8) <!--[rfced] Note that the YANG module has been updated per the formatting option of pyang. Please let us know any concerns. --> [JMC] No concerns from me. 9) <!--[rfced] Security Considerations: This text does not exactly match the text provided for security considerations of documents that contain YANG modules: https://wiki.ietf.org/group/ops/yang-security-guidelines Should this document be updated to match those? For example: usage of "all" vs. "some" and the additional sentences in the 5th paragraph (which start with "Logging" and "If logging"). Original: There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes should be considered sensitive or vulnerable in all network environments. Logging in particular is used to assess the state of systems and can be used to indicate a network compromise. If logging were to be disabled through malicious means, attacks may not be readily detectable. Therefore write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations and on network security. Corresponding text on https://wiki.ietf.org/group/ops/yang-security-guidelines: There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability: --> [JMC] Your mods to Security Considerations are good. I think breaking out the boilerplate text and the additional “logging” text into separate paragraphs is a good choice. Virtually the entire module is read-write, but the critical “top-level” nodes are “console”, “file”, and “remote” as each of these can have actions that disable logging. The “remote” branch can also be used as a means to exfiltrate data to a nefarious destination. 10) <!-- [rfced] References a) We have updated the Security Considerations section to reflect the guidelines shown here: https://wiki.ietf.org/group/ops/yang-security-guidelines. As a result, RFC 9000 has been removed from the Normative References. Please let us know if you prefer to cite it elsewhere. b) Please review the following reference. We note that a newer version of this standard was published in 2024; would you like to update this reference to the most current version? Original: [Std-1003.1-2008] Group, I. A. T. O., ""Chapter 9: Regular Expressions". The Open Group Base Specifications Issue 6, IEEE Std 1003.1-2008, 2016 Edition.", September 2016, <http://pubs.opengroup.org/onlinepubs/9699919799/>. Perhaps: [Std-1003.1-2024] The Open Group, "Chapter 9: Regular Expressions", The Open Group Base Specifications Issue 8, IEEE Std 1003.1-2024, 2024, <https://pubs.opengroup.org/onlinepubs/9799919799/>. --> [JMC] The new spec version is fine. 11) <!-- [rfced] Please review the line wrapping in Appendix A.1. Specifically, the original contained extra line breaks that were apparently not intended (e.g., before "ivate-key?"). We have updated the tree diagram to remove the extraneous line breaks. Please review; see https://www.rfc-editor.org/authors/rfc9742-rfcdiff.html and the examples below. (FYI, two hyphens are changed to one hyphen below for the sake of inclusion as a comment in the XML file.) Original: | | | | | | +-rw cleartext\ -pr ivate-key? | | | | | | binary | | | | | +-:(hidden-privat\ e-k ey) | | | | | | {hidden-p\ riv ate-keys}? Current: | | | | | | +-rw cleartext\ -private-key? | | | | | | binary | | | | | +-:(hidden-privat\ e-key) | | | | | | {hidden-p\ rivate-keys}? --> [JMC] This looks right to me. 12) <!--[rfced] FYI, we have updated this list as follows. Please review whether this conveys the intended meaning. Original: Removal of archive log files could occur when either or both: - log-file/number-of-files specified - the logging system can create up to log-file/number-of-files syslog archive files after which, the contents of the oldest archived file could be overwritten. - log-file/retention specified - the logging system can remove those syslog archive files whose file expiration time (file creation time plus the specified log-file/retention time) is prior to the current time. Current: Removal of archive log files could occur when either or both: * log-file/number-of-files is specified. The logging system can create up to log-file/number-of-files syslog archive files, after which the contents of the oldest archived file could be overwritten. * log-file/retention is specified. The logging system can remove those syslog archive files whose file expiration time (file creation time plus the specified log-file/retention time) is prior to the current time. --> [JMC] The current text reads fine. 13) <!-- [rfced] We noticed that the following term is used inconsistently. If there are no objections, we will use the form on the right. leafs vs. leaves --> [JMC] When it comes to YANG, I generally speak in “leafs” (knowing that is not the correct plural). In looking at RFC7950, they also pluralize “leaf” as “leafs”. So, I think the form on the left is more YANG-correct. 14) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> [JMC] I did not notice any non-inclusive verbiage. Joe
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
