Madison, who haven’t you heard from? I think you have my approval as well as Mahesh.
Joe — PGP Key : https://www.marcuscom.com/pgp.asc > On Apr 8, 2025, at 12:55, Madison Church <mchu...@staff.rfc-editor.org> wrote: > > Hi Authors, > > This is a friendly reminder that we have yet to hear back from some of you > regarding this document’s readiness for publication. > > Please review the AUTH48 status page > (http://www.rfc-editor.org/auth48/rfc9742) for further information and the > previous messages in this thread for pertinent communication. > > Thank you, > RFC Editor/mc > >> On Apr 1, 2025, at 1:26 PM, Madison Church <mchu...@staff.rfc-editor.org> >> wrote: >> >> Hi Authors, >> >> Thank you all for your replies! We have left the YANG module as is (Option >> A). All of our questions have now 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 (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 >> >> Diff files: >> https://www.rfc-editor.org/authors/rfc9742-diff.html (comprehensive diff) >> 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 Apr 1, 2025, at 10:57 AM, Agrahara Sreenivasa, Kiran Koushik >>>> <kirankoushik.agraharasreeniv...@verizonwireless.com> wrote: >>> >>> I second Mahesh below >>> >>> Thanks >>> >>>> On Tue, Apr 1, 2025 at 10:42 AM Mahesh Jethanandani >>>> <mjethanand...@gmail.com> wrote: >>> Hi Madison, >>> >>>> On Apr 1, 2025, at 8:21 AM, Joe Clarke (jclarke) <jcla...@cisco.com> wrote: >>>> >>>> >>>> >>>> 1) Thank you for pointing this out. With the initial AUTH48 email, we sent >>>> out the following query: >>>> >>>> 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}? >>>> --> >>>> >>>> This was due to the "{certificate-expiration-notification}?" line >>>> exceeding the character limit. With this in mind, should this change >>>> remain as is? >>>> [JMC] I suggested option A since that is established with what other >>>> modules do (and there is tooling to unwrap). If Mahesh strongly prefers >>>> B, I’m okay with that. >>> >>> Agree. Let us go with option A. >>> >>> Thanks. >>>> >>>> >>>> >>>> >>>>> The third comment has to do with the description of the example in >>>>> Section 6.1. It currently reads as: >>>>> >>>>> This example shows enabling console logging of syslogs of severity >>>>> critical. >>>>> >>>>> The statement structure seems awkward. How about “This example shows how >>>>> the console logging of syslog of severity critical can be enabled.”? >>>>> >>>>> Finally, a similar sentence restructuring for the description in Section >>>>> 6.2 also. >>>> >>>> 2) We have updated the sentence in Section 6.2 as follows. Please let us >>>> know if any updates are needed. Additionally, should "severity error" be >>>> plural in this sentence? >>>> >>>> Current: >>>> This example shows how the remote logging of syslogs to UDP destination >>>> >>>> foo.example.com for facility auth and severity error can be enabled. >>>> >>>> Perhaps: >>>> This example shows how the remote logging of syslogs to UDP destination >>>> >>>> foo.example.com for facility auth and severity errors can be enabled. >>>> [JMC] I think the current text is more accurate. The severity name (from >>>> the enumeration) is “error”. >>>> Joe >>> >>> Mahesh Jethanandani >>> mjethanand...@gmail.com > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
