Hi Mahesh,
Thank you for your reply! We have updated the document accordingly and have two
followup items.
> On Mar 21, 2025, at 6:04 PM, Mahesh Jethanandani <mjethanand...@gmail.com>
> wrote:
>
> Hi Madison,
>
> Sorry for getting to this review a little late. I have some minor editorial
> comments and are based on the side-by-side diffs that I am looking at.
>
> The first comment has to do with the tree diagram. I was trying to
> understand why one line has wrapped around, when the previous version of the
> tree diagram did not. Can that be fixed?
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?
> 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.
The updated files have been posted here (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
Updated diff files:
https://www.rfc-editor.org/authors/rfc9742-diff.html
https://www.rfc-editor.org/authors/rfc9742-rfcdiff.html (side by side)
https://www.rfc-editor.org/authors/rfc9742-auth48diff.html
https://www.rfc-editor.org/authors/rfc9742-auth48rfcdiff.html (side by side)
For the AUTH48 status page, please see:
https://www.rfc-editor.org/auth48/rfc9742
Thank you!
RFC Editor/mc
> Thanks.
>
> Mahesh Jethanandani
> mjethanand...@gmail.com
>
>> On Mar 21, 2025, at 9:49 PM, Madison Church <mchu...@staff.rfc-editor.org>
>> wrote:
>>
>> Hi Joe,
>>
>> Thank you for your reply! We have noted your approval on the AUTH48 status
>> page (see https://www.rfc-editor.org/auth48/rfc9742). Once we receive
>> approvals from all authors listed on the AUTH48 status page, we will move
>> this document forward in the publication process.
>>
>> Thank you!
>> RFC Editor/mc
>>
>>> On Mar 19, 2025, at 9:39 PM, Joe Clarke (jclarke) <jcla...@cisco.com> wrote:
>>>
>>> Approved from me. Thanks, Madison!
>>> Joe
>>> From: Madison Church <mchu...@staff.rfc-editor.org>
>>> Date: Wednesday, March 19, 2025 at 11:57
>>> To: Joe Clarke (jclarke) <jcla...@cisco.com>, Mahesh Jethanandani
>>> <mjethanand...@gmail.com>, cl...@clydewildes.com<cl...@clydewildes.com>,
>>> kirankoushik.agraharasreeniv...@verizonwireless.com<kirankoushik.agraharasreeniv...@verizonwireless.com>
>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>,
>>> netmod-...@ietf.org<netmod-...@ietf.org>, netmod-cha...@ietf.org
>>> <netmod-cha...@ietf.org>, kwat...@juniper.net <kwat...@juniper.net>, Warren
>>> Kumari <war...@kumari.net>,
>>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org>
>>> Subject: Re: AUTH48: RFC-to-be 9742 <draft-ietf-netmod-syslog-model-33> for
>>> your review
>>> Hi Authors,
>>>
>>> Joe - Thank you for your reply! We have updated the document as requested.
>>>
>>> All - Please review the updated files and let us know if you approve the
>>> document in its current form. Once we receive approvals from each person
>>> listed on the AUTH48 status page, we will move 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 Mar 18, 2025, at 3:58 AM, Joe Clarke (jclarke) <jcla...@cisco.com>
>>>> wrote:
>>>>
>>>> Madison, it chatting with our AD, we would like to make a few small
>>>> changes to the text to add clarity. Essentially, this involves changing
>>>> some instance of “configuration” to “management”.
>>>> First, the title of the document becomes, “A YANG Data Model for Syslog
>>>> Management”. Then, in the abstract:
>>>> OLD:
>>>> This document defines a YANG data model for the configuration of a syslog
>>>> process. It is intended that this data model be used by vendors who
>>>> implement syslog collectors in their systems.
>>>> NEW:
>>>> This document defines a YANG data model for the management of a syslog
>>>> process. It is intended that this data model be used by vendors who
>>>> implement syslog collectors in their systems.
>>>> Then, in Section 1:
>>>> OLD:
>>>> This document defines a YANG [RFC7950] configuration data model
>>>> NEW:
>>>> This document defines a YANG [RFC7950] data model
>>>> Then, in the YANG module in Section 5.1:
>>>> OLD:
>>>> This module contains a collection of YANG definitions for syslog
>>>> configuration.
>>>> NEW:
>>>> This module contains a collection of YANG definitions for syslog
>>>> management.
>>>> Joe
>>>> From: Madison Church <mchu...@staff.rfc-editor.org>
>>>> Date: Monday, March 17, 2025 at 15:24
>>>> To: Joe Clarke (jclarke) <jcla...@cisco.com>, Mahesh Jethanandani
>>>> <mjethanand...@gmail.com>, cl...@clydewildes.com<cl...@clydewildes.com>,
>>>> kirankoushik.agraharasreeniv...@verizonwireless.com<kirankoushik.agraharasreeniv...@verizonwireless.com>
>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>, netmod-...@ietf.org
>>>> <netmod-...@ietf.org>, netmod-cha...@ietf.org <netmod-cha...@ietf.org>,
>>>> kwat...@juniper.net <kwat...@juniper.net>, Warren Kumari
>>>> <war...@kumari.net>, auth48archive@rfc-editor.org
>>>> <auth48archive@rfc-editor.org>
>>>> Subject: Re: AUTH48: RFC-to-be 9742 <draft-ietf-netmod-syslog-model-33>
>>>> for your review
>>>> Hi Authors,
>>>>
>>>> Joe - Thank you for the confirmation!
>>>>
>>>> All - Now that our questions have 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 have been posted here (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
>>>>
>>>> Updated diff files:
>>>> https://www.rfc-editor.org/authors/rfc9742-diff.html (comprehensive edits)
>>>> 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 Mar 14, 2025, at 1:53 AM, Joe Clarke (jclarke) <jcla...@cisco.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>> [rfced] Thank you for pointing this out (and apologies for missing this
>>>>> earlier). We have updated the Security Considerations section to match
>>>>> what appears in 8407bis [1].
>>>>>
>>>>> Additionally, please note that we have removed the following text from
>>>>> the Security Considerations to match 8407bis. If this text should be
>>>>> re-added to the paragraph (or if there are any further updates needed),
>>>>> please let us know.
>>>>> [JMC] You know, I don’t think it’s needed in light of the boilerplate
>>>>> text indicating an impact to operations if these data nodes are not
>>>>> protected. I’m good with the sec considerations as they read now.
>>>>> Joe
>>
>>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
