Hi Madison, Hmm! I thought I had given my approval. Anyway, here it is. And thanks.
> On Apr 8, 2025, at 10:11 AM, Madison Church <mchu...@staff.rfc-editor.org> > wrote: > > 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 >>> > Mahesh Jethanandani mjethanand...@gmail.com
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
