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
