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
