A YANG Data Model for Syslog Configuration
draft-ietf-netmod-syslog-model-33
Yes
Warren Kumari
No Objection
Erik Kline
Francesca Palombini
Jim Guichard
Murray Kucherawy
Orie Steele
Recuse
Note: This ballot was opened for revision 32 and is now closed.
Paul Wouters
(was Discuss)
Yes
Comment
(2024-09-18)
Sent
Thanks for addressing my concerns and undoing my suggestion that didn't take the Historic nature of RFC6587 into account :)
Warren Kumari
Yes
Erik Kline
No Objection
Francesca Palombini
No Objection
Gunter Van de Velde
(was Discuss)
No Objection
Comment
(2024-09-13 for -32)
Sent for earlier
# Gunter Van de Velde, RTG AD, comments for draft-ietf-netmod-syslog-model-32 # Many thanks for writing this document and for resolving the raised discuss by providing more accurate text. #DISCUSS (resolved) ======================= ## (resolved (2024 Sept 13)) I am raising a DISCUSS. The inclusion of vendor-specific details in the main body of a standards-track document is unexpected (see line 165). If the Working Group wishes to document vendor-specific properties, it should be considered informational and explicitly placed in an appendix for clarity. Upon reviewing the YANG module, I note that the vendor-specific augmentations are already documented in the appendix. It may be beneficial for clarity to add a note at line 165 indicating that the referenced vendor-specific augmentations are detailed in Appendix A.1 and A.2. #GENERIC COMMENTS #================ ## The yang module has a significant amount of feature statement defines an optional capability that may or may not be supported by an implementation of the YANG module. Some of these at first glance look rather feasible for being supported by default. Has the list of optional capabilities been verified with existing syslog implementations? ## Some lines in the pyang tree output are wrapped, which affects the overall presentation. While this is not ideal, I do not have a better suggestion at this time. In my view, using abbreviations for leaf names would be less desirable from a modeling perspective than allowing wrapped lines within an IETF YANG standards document. #DETAILED COMMENTS #================= ##classified as [minor] and [major] 117 2. Terminology 118 119 The term "originator" is defined in [RFC5424] : an "originator" 120 generates syslog content to be carried in a message. 121 122 The term "relay" is defined in [RFC5424] : a "relay" forwards 123 messages, accepting messages from originators or other relays and 124 sending them to collectors or other relays 125 126 The term "collectors" is defined in [RFC5424] : a "collector" gathers 127 syslog content for further analysis. 128 129 The term "action" refers to the processing that takes place for each 130 syslog message received. [minor] rewrite suggestion for making the Terminology section more structured: " The following terms are used throughout this document: Originator: As defined in [RFC5424], an "originator" refers to an entity that generates syslog content to be included in a message. Relay: As defined in [RFC5424], a "relay" is an entity that forwards syslog messages. It accepts messages from originators or other relays and sends them to collectors or other relays. Collector: As defined in [RFC5424], a "collector" refers to an entity that gathers syslog messages for further analysis. Action: Refers to the processing applied to each syslog message received. " 160 This document addresses the common leafs between implementations and 161 creates a common model, which can be augmented with proprietary 162 features, if necessary. This model is designed to be very simple for 163 maximum flexibility. [minor] rewrite proposal: " This document identifies common elements across implementations and defines a shared model, which can be augmented with proprietary features as needed. The model is intentionally designed to be simple, ensuring maximum flexibility. "
Jim Guichard
No Objection
Murray Kucherawy
No Objection
Orie Steele
No Objection
Roman Danyliw
No Objection
Comment
(2024-09-16 for -32)
Sent
Thank you to Francis Dupont for the GENART review. ** Section 10 says “ There are no RPC operations defined in this YANG module.” However, in Figure 1 there is: | | +---x generate-csr {csr-generation}? Which appears to be generate-csr-grouping from draft-ietf-netconf-crypto-types. Should the Security Considerations of draft-ietf-netconf-crypto-types be mentioned? Is this Section 10 language of “no RPC operations defined”accurate – is it because the thinking is that this functionality is imported (via ct:asymmetric-key-pair-with-cert-grouping)?
Zaheduzzaman Sarker
No Objection
Comment
(2024-09-18 for -32)
Not sent
Thanks for working on this specificatoin. No object from transport protocol aspects. (no syslog protocol over QUIC yet ?? :-))
Éric Vyncke
No Objection
Comment
(2024-09-04 for -32)
Sent
Thanks for the work done in this document, I have nevertheless some non-blocking comments (see below) and I am also curious why this document was done in NETMOD rather than OPSAWG (as it seems that many YANG models are authored in OPSAWG even if NETMOD charter would allow it). # Meta data Should Mahesh's new affiliation be specified ? # Abstract and title It is unclear that the YANG model is only for the collector part of syslog. # Section 1 What is the `target system` ? At first reading, it seems to be the collector system, if so, should the I-D be consistent in vocabulary ? # Section 5.1 While I am not a YANG expert, isn't it weird to replicate the facility-filter under console, remote, and file ? Or is it just a caveat of the tree diagram when it expands the facility-filter grouping several times ? Would it be possible to import TLS and authentication from other YANG models ?
Mahesh Jethanandani
Recuse
Comment
(2024-09-03 for -32)
Sent
As an author of the draft, I am recusing myself.