Madison, it chatting with our AD, we would like to make a few small changes to the text to add clarity. Essentially, this involves changing some instance of “configuration” to “management”.
First, the title of the document becomes, “A YANG Data Model for Syslog Management”. Then, in the abstract: OLD: This document defines a YANG data model for the configuration of a syslog process. It is intended that this data model be used by vendors who implement syslog collectors in their systems. NEW: This document defines a YANG data model for the management of a syslog process. It is intended that this data model be used by vendors who implement syslog collectors in their systems. Then, in Section 1: OLD: This document defines a YANG [RFC7950] configuration data model NEW: This document defines a YANG [RFC7950] data model Then, in the YANG module in Section 5.1: OLD: This module contains a collection of YANG definitions for syslog configuration. NEW: This module contains a collection of YANG definitions for syslog management. Joe From: Madison Church <mchu...@staff.rfc-editor.org> Date: Monday, March 17, 2025 at 15:24 To: Joe Clarke (jclarke) <jcla...@cisco.com>, Mahesh Jethanandani <mjethanand...@gmail.com>, cl...@clydewildes.com <cl...@clydewildes.com>, kirankoushik.agraharasreeniv...@verizonwireless.com <kirankoushik.agraharasreeniv...@verizonwireless.com> Cc: RFC Editor <rfc-edi...@rfc-editor.org>, netmod-...@ietf.org <netmod-...@ietf.org>, netmod-cha...@ietf.org <netmod-cha...@ietf.org>, kwat...@juniper.net <kwat...@juniper.net>, Warren Kumari <war...@kumari.net>, auth48archive@rfc-editor.org <auth48archive@rfc-editor.org> Subject: Re: AUTH48: RFC-to-be 9742 <draft-ietf-netmod-syslog-model-33> for your review Hi Authors, Joe - Thank you for the confirmation! All - Now that our questions have been addressed, please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process. Updated files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9742.txt https://www.rfc-editor.org/authors/rfc9742.pdf https://www.rfc-editor.org/authors/rfc9742.html https://www.rfc-editor.org/authors/rfc9742.xml Updated diff files: https://www.rfc-editor.org/authors/rfc9742-diff.html (comprehensive edits) https://www.rfc-editor.org/authors/rfc9742-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9742-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9742-auth48rfcdiff.html (side by side) For the AUTH48 status page, see: https://www.rfc-editor.org/auth48/rfc9742 Thank you, RFC Editor/mc > On Mar 14, 2025, at 1:53 AM, Joe Clarke (jclarke) <jcla...@cisco.com> wrote: > > > [rfced] Thank you for pointing this out (and apologies for missing this > earlier). We have updated the Security Considerations section to match what > appears in 8407bis [1]. > > Additionally, please note that we have removed the following text from the > Security Considerations to match 8407bis. If this text should be re-added to > the paragraph (or if there are any further updates needed), please let us > know. > [JMC] You know, I don’t think it’s needed in light of the boilerplate text > indicating an impact to operations if these data nodes are not protected. > I’m good with the sec considerations as they read now. > Joe
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
