Hi Joe, Thank you for your reply! As of right now, we are still awaiting approvals from Mahesh, Clyde, and Kiran (see https://www.rfc-editor.org/auth48/rfc9742).
Thank you, RFC Editor/mc > On Apr 8, 2025, at 9:56 AM, Joe Clarke (jclarke) <jcla...@cisco.com> wrote: > > 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
