Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 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. --> 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. --> 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. --> 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). 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}? --> 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? 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." --> 8) <!--[rfced] Note that the YANG module has been updated per the formatting option of pyang. Please let us know any concerns. --> 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: --> 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/>. --> 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}? --> 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. --> 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 --> 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. --> Thank you. RFC Editor/mc/ar On Mar 3, 2025, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/03/03 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-edi...@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9742.xml https://www.rfc-editor.org/authors/rfc9742.html https://www.rfc-editor.org/authors/rfc9742.pdf https://www.rfc-editor.org/authors/rfc9742.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9742-diff.html https://www.rfc-editor.org/authors/rfc9742-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9742-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9742 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9742 (draft-ietf-netmod-syslog-model-33) Title : A YANG Data Model for Syslog Configuration Author(s) : J. Clarke, Ed., M. Jethanandani, Ed., C. Wildes, Ed., K. Koushik, Ed. WG Chair(s) : Kent Watsen, Lou Berger Area Director(s) : Warren Kumari, Mahesh Jethanandani -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
