Thanks, Joe, for working through all the comments. There is one item that was missed, and a couple of updates. See inline.
> On Mar 5, 2025, at 5:45 AM, Joe Clarke (jclarke) <jcla...@cisco.com> wrote: > > 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). > --> The updated text sounds better. > > > 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. The Security Considerations section template has been further updated by draft-ietf-netmod-rfc8407bis. In particular, the second paragraph has been updated. This will affect your next point #10. This is a reminder to myself to get the yang-security-guidelines page updated once rfc8407bis is approved. > > > > 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. Once we reintroduce the template from 8407bis, it will bring back the reference to RFC9000. > > 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 Mahesh Jethanandani mjethanand...@gmail.com
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
