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.
COMMENT:
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. "
DISCUSS
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.
COMMENT:
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. "