Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt
Juergen, Thanks very much for your detailed review. I have updated the document with your feedback and have provided responses for every item, inline below. On 8/5/16, 3:36 AM, "Juergen Schoenwaelder" wrote: On Fri, Jul 08, 2016 at 10:37:06PM +, Clyde Wildes (cwildes) wrote: > Juergen, > > Thanks for your detailed review! > > I addressed all of your comments in the latest draft. Thanks for the update. As my role as a YANG doctoc and someone generally interested, I took another look at the syslog model. I think it has much improved and is close to be done. But of course, I always find stuff to comment on... * Document Should the title be changed to A YANG Data Model for Syslog Configuration to match existing YANG RFC names and to indicate that the scope is configuration (as stated in the abstract)? [clyde] Adopted. Why is the term message originator needed? The definition says: The term "message originator" is derived from the term "originator" as defined in [RFC5424]: an "originator" generates syslog content to be carried in a message. This does not explain why 'originator' is not good enough and why a new term is needed. What the figure in section 3 shows looks pretty much as originators as well. (BTW, it might be nice to give figures a number and a caption - makes it easier to refer to them.) [clyde] I have changed the term to ‘originator’ and have added labels to the figures. I am also not sure why the term "message distributor" is needed; is this not just a 'relay' in the RFC 5424 sense? Or is your message distributor a combination of a 'relay' and a 'collector'? I think at least some explanation should be given how these terms fit together. I also note that the terms "message distributor" and "message originator" are never used in the YANG model definition itself; so if we can simply use RFC 5424 terms in the introductory part I would find that simpler. (I am also not clear whether I would call a Log File a Message Distributor as the figure in section 3 suggests; for me these are actually what RFC 5424 calls collectors.) [clyde] I have simplified this to collector. You wrote "to configure one or more syslog processes" and I wonder what you mean with 'syslog processes' here and why you stress 'multiple'. Is there anything in the data model that was designed specifically to support _multiple_ syslog processes? Is syslog process here the same as 'message distributor'? If so, use a single term; if not, please explain the difference. [clyde] I have changed the wording to “to configure the syslog feature”. You wrote: This module can be used to configure the syslog application conceptual layer [RFC5424]. Is this statement correct? How do I use the data model to configure the list of originators shown in section 3? [clyde] The list of originators is fixed for each syslog implementation. A better wording might be “This module can be used to configure the syslog application conceptual layers as implemented on the target system [RFC5424].” You wrote: The leaves in the base syslog model log-input-transports container correspond to remote message originators or remote message relays. The leaves in the base syslog model log-actions container correspond to each message distributor: I could not find log-input-transports and log-actions anywhere, I think renaming has not been reflected in the text yet. [clyde] log-input-transports was removed in a previous edit. This paragraph has been removed from the draft. I would prefer if the examples would be trimmed down to show just the XML config and not an entire NETCONF RPC exchange in order to reduce noise. Also reduce the number of namespace definitions to the minimum needed. I am not sure the namespace used in Appendix A.1 is a good idea. Perhaps use "http://example.com/ethernet"; and in general use example.com for example domain names (and not vendor.com) [clyde] Adopted. * ietf-syslog-types Instead of just 'Alert Level Msg' in the description, perhaps write full sentence that is more descriptive, e.g., "The severity level 'Alert' indicating that an action must be taken immediately." Note that Table 2 in RFC 5424 provides phrases describing syslog message severities. [clyde] Adopted. * ietf-syslog The commented out reference to ietf-tls-client needs to be resolved. [clyde] I need direction from Kent for this. I will work with him and will revise this section in a future update. Is the regular expression matching cl
Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt
On Fri, Jul 08, 2016 at 10:37:06PM +, Clyde Wildes (cwildes) wrote: > Juergen, > > Thanks for your detailed review! > > I addressed all of your comments in the latest draft. Thanks for the update. As my role as a YANG doctoc and someone generally interested, I took another look at the syslog model. I think it has much improved and is close to be done. But of course, I always find stuff to comment on... * Document Should the title be changed to A YANG Data Model for Syslog Configuration to match existing YANG RFC names and to indicate that the scope is configuration (as stated in the abstract)? Why is the term message originator needed? The definition says: The term "message originator" is derived from the term "originator" as defined in [RFC5424]: an "originator" generates syslog content to be carried in a message. This does not explain why 'originator' is not good enough and why a new term is needed. What the figure in section 3 shows looks pretty much as originators as well. (BTW, it might be nice to give figures a number and a caption - makes it easier to refer to them.) I am also not sure why the term "message distributor" is needed; is this not just a 'relay' in the RFC 5424 sense? Or is your message distributor a combination of a 'relay' and a 'collector'? I think at least some explanation should be given how these terms fit together. I also note that the terms "message distributor" and "message originator" are never used in the YANG model definition itself; so if we can simply use RFC 5424 terms in the introductory part I would find that simpler. (I am also not clear whether I would call a Log File a Message Distributor as the figure in section 3 suggests; for me these are actually what RFC 5424 calls collectors.) You wrote "to configure one or more syslog processes" and I wonder what you mean with 'syslog processes' here and why you stress 'multiple'. Is there anything in the data model that was designed specifically to support _multiple_ syslog processes? Is syslog process here the same as 'message distributor'? If so, use a single term; if not, please explain the difference. You wrote: This module can be used to configure the syslog application conceptual layer [RFC5424]. Is this statement correct? How do I use the data model to configure the list of originators shown in section 3? You wrote: The leaves in the base syslog model log-input-transports container correspond to remote message originators or remote message relays. The leaves in the base syslog model log-actions container correspond to each message distributor: I could not find log-input-transports and log-actions anywhere, I think renaming has not been reflected in the text yet. I would prefer if the examples would be trimmed down to show just the XML config and not an entire NETCONF RPC exchange in order to reduce noise. Also reduce the number of namespace definitions to the minimum needed. I am not sure the namespace used in Appendix A.1 is a good idea. Perhaps use "http://example.com/ethernet"; and in general use example.com for example domain names (and not vendor.com) * ietf-syslog-types Instead of just 'Alert Level Msg' in the description, perhaps write full sentence that is more descriptive, e.g., "The severity level 'Alert' indicating that an action must be taken immediately." Note that Table 2 in RFC 5424 provides phrases describing syslog message severities. * ietf-syslog The commented out reference to ietf-tls-client needs to be resolved. Is the regular expression matching clearly enough specified? How do you deal with flags such as REG_ICASE? Are these what is sometimes referred to as extended regular expressions? I wonder whether names can be further streamlined, e.g. log-selector -> selector log-facility -> facility no-log-facility -> facility facility -> name This would turn all critical into this all critical BTW, is the following valid? kern notice equal kern debug equal I do not think this is valid but would it not be desirable to support multiple filters on the same facility? Good old BSD like syslog daemons do understand configurations such as kern.notice;kern.debug: |/dev/xconsole If my syslog implementation supports structured dat
Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt
Juergen, Thanks for your detailed review! I addressed all of your comments in the latest draft. Regards, Clyde On 6/15/16, 8:29 AM, "netmod on behalf of Juergen Schoenwaelder" wrote: >Hi, > >Dan Romascanu encouraged me to look at this I-D as part of his efforts >to organize YANG document reviews. Since the YANG definitions are not >consistent with the tree diagram, I have not really looked at the YANG >definitions yet. So the comments below are essentially about the >surrounding document structure, terminology, etc. > >- Abstract: The 'which is used to convey event notification messages' > may relate to 'the Syslog protocol' or 'a data model' and hence the > sentence is I think potentially confusing. Perhaps simply remove the > phrase altogether? Readers who do not know what SYSLOG is should > stop reading here anyway. Or break the sentence into two to make the > structure clearer. Perhaps add one more sentence describing what the > scope of the data model is. > >- The text uses Syslog, syslog, and SYSLOG. It is not clear what the > difference is (if any). If there is no semantic difference, I > suggest to pick one writing style (and 5424 seems to prefer all > lowercase except in cases where a sentence starts etc). > >- Change title of 4.1 to 'The ietf-syslog-types Module' and 4.2 > to 'The ietf-syslog Module' or something similar and consider > changing the title of section 4 to "Syslog YANG Modules" since > it contains the definitions of the modules themselves. > >- In section 2, should 'monitor and control' be 'configure and > monitor' in section 2? Are there actually definitions that support > monitoring? Perhaps the scope is just configuration? Otherwise, I > would have expected to see a bunch of basic counters (messages > received, forwarded, dropped, the usual monitoring stuff). > >- In section 2, s/network management agents such as NETCONF/network > management protocols such as NETCONF/ > >- In section 2, the phrase 'This module' is a hanging reference. There > is no prior text talking about a module. Perhaps replace with 'The > data model' > >- I did not find the term 'message distributor' in RFC 5424. The > figure first made me assume that only a console, log buffers, or log > files are message distributors but later it was stated that relays > and collectors (RFC 5424 defined terms) are also 'message > distributors'. Perhaps it helps to clearly spell out terms imported > from RFC 5424 and to clearly define any additional terms that go > beyond what is defined in RFC 5424. > >- Is it possible to shorten 'log-input-transports' to simply > 'log-inputs' (en par with log-actions)? And since both containers > are under syslog, perhaps even the 'log-' prefix is not needed and > all we have are /syslog/inputs and /syslog/actions? (I generally > find it useful to look at the resulting paths and whether they are > 'engineer friendly'. > >- I guess I have to define multiple /syslog/input/receiver in order to > listen on multiple UDP ports, e.g. to support both 0.0.0.0:514 and > [::]:514? This may be just find - just checking that this is the > idea. > >- I actually do not find the definition of log-input-transports in the > YANG model. It seems the tree diagram is not consistent with the > YANG model. So I can't judge what the structured-data boolean flag > is doing or what the syslog-sign presence container would do for > inputs. > >- The security considerations are quite generic; I think the template > asks for a more specific discussion. > >- I am not sure why RFC 6020 is an informative reference and why all > the normative references are actually normative. It might be useful > to go over the list to make sure we get the normative / informative > distinction right. > >- My understanding is that RFC 5424 numbers facilities and there is a > hard limit on the number of facilities that the protocol can > distinguish. RFC 5424 says: > >Facility values MUST be in the range of 0 to 23 inclusive. > > Given this, the 'extending facilities' appendix does not make much > sense to me. And given the fact that the number of facilities is > fixed (which is due to the way things are encoded in RFC 5424), I am > not even sure that using an identity instead of an enumeration is > useful (except if we expect a future version of SYSLOG to use a very > different encoding of facilities). I mean, to stay within the bounds > of RFC 5424, all one can do is to add an identity that maps to an > already allocated code point. > >- Do not use 1.1.1.1 as an example IP address, consider using an IPv6 > address from the IPv6 example address space. > >- Section 4.3 should not be in Section 4 and the title 'A Syslog > Example' is kind of misleading since the text shows NETCONF messages > operating on the SYSLOG YANG data model. I suggest to move 4.3 to > a new top-level section 5 "Usage Examples". Does it make sense to > show some complete example configs for typica
Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt
I have concerns that generally broadening the scope is the right
direction. There are many event logging systems and not all of them
follow the concepts used by syslog. I rather have this model specific
to syslog (because this is something the IETF standardized, something
we understand and it is a manageable scope).
I would rather state clearly (in the appendix) that additional
facilities may not work with the syslog protocol as defined in RFC
5424 and hence such facilities may only apply for local syslog-like
logging functionality.
/js
On Tue, Jun 21, 2016 at 09:28:21PM +, Sterne, Jason (Nokia - CA) wrote:
> How about some of the following changes to shift the focus slightly from
> "Syslog" to "configuring event logging" ?
>
> ###
> (A) Replace the introduction with the following:
> ###
>
> 1. Introduction
>
>Operating systems, processes and applications generate messages
>indicating their own status or the occurrence of events. These
>log event messages are useful for managing and/or debugging the network
> and its
>services.
>
>Since each process, application and operating system was written
>somewhat independently, there is limited uniformity to the content of
>log event messages. There is, however, some common structure to
>log event messages and processing. The BSD Syslog protocol is a widely
> adopted protocol that
>is used for transmission and processing of log event messages. Some of
> the definitions and concepts from [RFC5424] are used in this model to create
> a common framework for configuration of log event handling on a device.
>
>Essentially, an event logging process receives messages (from the kernel,
>processes, applications or other event logging processes) and processes
>those. The processing involves logging to a local file, displaying
>on console, user terminal, and/or relaying to event logging processes on
>other machines. The processing is determined by the "facility" that
>originated the message and the "severity" assigned to the message by
>the facility.
>
> ###
> (B) Add the following paragraph somewhere in section "3. Design of the
> SYSLOG Model"
> ###
>
> The syslog model employs the use of an extensible 'identity' for
> 'syslog-facility' along with a pre-defined set of standard facilities based
> on [RFC5424]. The standard facilities are required when log event messages
> are transmitted from one device to another using the Syslog protocol
> [RFC5424] (i.e. using the 'remote' log-action). Many vendors, however, use
> proprietary extended facility lists to manage event logging so an extensible
> identity was selected as the type for 'syslog-facility'. See Appendix A
> section A.1 for an example of a vendor-specific extension of the
> syslog-facility identities.
>
> ##
> (C) Replace the definition of syslog-facility as follows
>
> identity syslog-facility {
> description
> "This identity is used as a base for event log facilities.
>A standard set of facilities based on RFC 5424 is defined
>and it is expected that implementations may extend this
>list with proprietary facilities. The standard
>RFC 5424 facility values should be used for log events that
>are exchanged between devices using the Syslog protocol.";
> }
>
> ##
> (D) Replace the definition of 'container remote' as follows
> ##
>
> container remote {
> description
> "This container describes the configuration parameters for
>transmission of log event messages to another device using
> the Syslog protocol [RFC5424].";
>
>
> Regards,
> Jason
>
> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> Sent: Friday, June 17, 2016 12:09
> To: Sterne, Jason (Nokia - CA)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt
>
> Then this probably needs to be more clearly spelled out.
>
> /js
>
> On Fri, Jun 17, 2016 at 01:34:31PM +, Sterne, Jason (Nokia - CA) wrote:
> > Hi Juergen,
> >
> > This model may be used in cases where no events are sent on any wire. Only
> > events sent on a 'remote' log-action would n
Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt
How about some of the following changes to shift the focus slightly from
"Syslog" to "configuring event logging" ?
###
(A) Replace the introduction with the following:
###
1. Introduction
Operating systems, processes and applications generate messages
indicating their own status or the occurrence of events. These
log event messages are useful for managing and/or debugging the network and
its
services.
Since each process, application and operating system was written
somewhat independently, there is limited uniformity to the content of
log event messages. There is, however, some common structure to
log event messages and processing. The BSD Syslog protocol is a widely
adopted protocol that
is used for transmission and processing of log event messages. Some of the
definitions and concepts from [RFC5424] are used in this model to create a
common framework for configuration of log event handling on a device.
Essentially, an event logging process receives messages (from the kernel,
processes, applications or other event logging processes) and processes
those. The processing involves logging to a local file, displaying
on console, user terminal, and/or relaying to event logging processes on
other machines. The processing is determined by the "facility" that
originated the message and the "severity" assigned to the message by
the facility.
###
(B) Add the following paragraph somewhere in section "3. Design of the SYSLOG
Model"
###
The syslog model employs the use of an extensible 'identity' for
'syslog-facility' along with a pre-defined set of standard facilities based on
[RFC5424]. The standard facilities are required when log event messages are
transmitted from one device to another using the Syslog protocol [RFC5424]
(i.e. using the 'remote' log-action). Many vendors, however, use proprietary
extended facility lists to manage event logging so an extensible identity was
selected as the type for 'syslog-facility'. See Appendix A section A.1 for an
example of a vendor-specific extension of the syslog-facility identities.
##
(C) Replace the definition of syslog-facility as follows
identity syslog-facility {
description
"This identity is used as a base for event log facilities.
A standard set of facilities based on RFC 5424 is defined
and it is expected that implementations may extend this
list with proprietary facilities. The standard
RFC 5424 facility values should be used for log events that
are exchanged between devices using the Syslog protocol.";
}
##
(D) Replace the definition of 'container remote' as follows
##
container remote {
description
"This container describes the configuration parameters for
transmission of log event messages to another device using
the Syslog protocol [RFC5424].";
Regards,
Jason
-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: Friday, June 17, 2016 12:09
To: Sterne, Jason (Nokia - CA)
Cc: netmod@ietf.org
Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt
Then this probably needs to be more clearly spelled out.
/js
On Fri, Jun 17, 2016 at 01:34:31PM +, Sterne, Jason (Nokia - CA) wrote:
> Hi Juergen,
>
> This model may be used in cases where no events are sent on any wire. Only
> events sent on a 'remote' log-action would need to conform to RFC5424. In
> that case there is the "destination-facility" override if needed.
>
> But for many of the other uses of the model for just configuring logging (and
> event filtering) to buffer, file, console, etc it is very useful to have the
> extensible facility concept.
>
> Jason
>
> -Original Message-
> From: Juergen Schoenwaelder
> [mailto:j.schoenwael...@jacobs-university.de]
> Sent: Friday, June 17, 2016 2:38
> To: Sterne, Jason (Nokia - CA)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] partial review of
> draft-ietf-netmod-syslog-model-08.txt
>
> In ietf-syslog-types, there is a mapping of facility names to a limited
> number space on the wire. Unfortunately, this mapping is not available in a
> machine readable form. But for those names listed in RFC 5424, there is at
> least a mapping defined in human readable form in the description clauses.
> The examples given in A.1 are completely silent about which number is used on
> the wire
Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt
Then this probably needs to be more clearly spelled out. /js On Fri, Jun 17, 2016 at 01:34:31PM +, Sterne, Jason (Nokia - CA) wrote: > Hi Juergen, > > This model may be used in cases where no events are sent on any wire. Only > events sent on a 'remote' log-action would need to conform to RFC5424. In > that case there is the "destination-facility" override if needed. > > But for many of the other uses of the model for just configuring logging (and > event filtering) to buffer, file, console, etc it is very useful to have the > extensible facility concept. > > Jason > > -Original Message- > From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] > Sent: Friday, June 17, 2016 2:38 > To: Sterne, Jason (Nokia - CA) > Cc: netmod@ietf.org > Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt > > In ietf-syslog-types, there is a mapping of facility names to a limited > number space on the wire. Unfortunately, this mapping is not available in a > machine readable form. But for those names listed in RFC 5424, there is at > least a mapping defined in human readable form in the description clauses. > The examples given in A.1 are completely silent about which number is used on > the wire. > > I think this is a problem if you consider setups where a relay is expected to > filter on facility values. When an originator uses facility 'vendor:foo', > what will that facility be from the viewpoint of a relay? > > /js > > On Thu, Jun 16, 2016 at 09:45:06PM +, Sterne, Jason (Nokia - CA) wrote: > > Hi Juergen, > > > > About the identities vs enum for 'facilities' -> I'm pretty sure it was > > discussed on the list previously but I think the applicability of the model > > is going to be much better if we allow extensible facilities. Several > > implementations use proprietary facility names along with RFC5424 facility > > names in a unified way to configure logging. > > > > IMO this YANG model isn't exactly trying to match & reproduce RFC5424. > > RFC5424 is more about the format of syslog messages on a wire. But this > > syslog YANG model is more about how devices configure logging. > > > > So I'm strongly in favor of seeing the facilities stay as an identity. > > > > Regards, > > Jason > > > > -Original Message- > > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Wednesday, June 15, 2016 11:30 > > To: netmod@ietf.org > > Subject: [netmod] partial review of > > draft-ietf-netmod-syslog-model-08.txt > > > > Hi, > > > > Dan Romascanu encouraged me to look at this I-D as part of his efforts to > > organize YANG document reviews. Since the YANG definitions are not > > consistent with the tree diagram, I have not really looked at the YANG > > definitions yet. So the comments below are essentially about the > > surrounding document structure, terminology, etc. > > > > - Abstract: The 'which is used to convey event notification messages' > > may relate to 'the Syslog protocol' or 'a data model' and hence the > > sentence is I think potentially confusing. Perhaps simply remove the > > phrase altogether? Readers who do not know what SYSLOG is should > > stop reading here anyway. Or break the sentence into two to make the > > structure clearer. Perhaps add one more sentence describing what the > > scope of the data model is. > > > > - The text uses Syslog, syslog, and SYSLOG. It is not clear what the > > difference is (if any). If there is no semantic difference, I > > suggest to pick one writing style (and 5424 seems to prefer all > > lowercase except in cases where a sentence starts etc). > > > > - Change title of 4.1 to 'The ietf-syslog-types Module' and 4.2 > > to 'The ietf-syslog Module' or something similar and consider > > changing the title of section 4 to "Syslog YANG Modules" since > > it contains the definitions of the modules themselves. > > > > - In section 2, should 'monitor and control' be 'configure and > > monitor' in section 2? Are there actually definitions that support > > monitoring? Perhaps the scope is just configuration? Otherwise, I > > would have expected to see a bunch of basic counters (messages > > received, forwarded, dropped, the usual monitoring stuff). > > > > - In section 2, s/network management agents such as NETCONF/network
Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt
Hi Juergen, This model may be used in cases where no events are sent on any wire. Only events sent on a 'remote' log-action would need to conform to RFC5424. In that case there is the "destination-facility" override if needed. But for many of the other uses of the model for just configuring logging (and event filtering) to buffer, file, console, etc it is very useful to have the extensible facility concept. Jason -Original Message- From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] Sent: Friday, June 17, 2016 2:38 To: Sterne, Jason (Nokia - CA) Cc: netmod@ietf.org Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt In ietf-syslog-types, there is a mapping of facility names to a limited number space on the wire. Unfortunately, this mapping is not available in a machine readable form. But for those names listed in RFC 5424, there is at least a mapping defined in human readable form in the description clauses. The examples given in A.1 are completely silent about which number is used on the wire. I think this is a problem if you consider setups where a relay is expected to filter on facility values. When an originator uses facility 'vendor:foo', what will that facility be from the viewpoint of a relay? /js On Thu, Jun 16, 2016 at 09:45:06PM +, Sterne, Jason (Nokia - CA) wrote: > Hi Juergen, > > About the identities vs enum for 'facilities' -> I'm pretty sure it was > discussed on the list previously but I think the applicability of the model > is going to be much better if we allow extensible facilities. Several > implementations use proprietary facility names along with RFC5424 facility > names in a unified way to configure logging. > > IMO this YANG model isn't exactly trying to match & reproduce RFC5424. > RFC5424 is more about the format of syslog messages on a wire. But this > syslog YANG model is more about how devices configure logging. > > So I'm strongly in favor of seeing the facilities stay as an identity. > > Regards, > Jason > > -Original Message- > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, June 15, 2016 11:30 > To: netmod@ietf.org > Subject: [netmod] partial review of > draft-ietf-netmod-syslog-model-08.txt > > Hi, > > Dan Romascanu encouraged me to look at this I-D as part of his efforts to > organize YANG document reviews. Since the YANG definitions are not consistent > with the tree diagram, I have not really looked at the YANG definitions yet. > So the comments below are essentially about the surrounding document > structure, terminology, etc. > > - Abstract: The 'which is used to convey event notification messages' > may relate to 'the Syslog protocol' or 'a data model' and hence the > sentence is I think potentially confusing. Perhaps simply remove the > phrase altogether? Readers who do not know what SYSLOG is should > stop reading here anyway. Or break the sentence into two to make the > structure clearer. Perhaps add one more sentence describing what the > scope of the data model is. > > - The text uses Syslog, syslog, and SYSLOG. It is not clear what the > difference is (if any). If there is no semantic difference, I > suggest to pick one writing style (and 5424 seems to prefer all > lowercase except in cases where a sentence starts etc). > > - Change title of 4.1 to 'The ietf-syslog-types Module' and 4.2 > to 'The ietf-syslog Module' or something similar and consider > changing the title of section 4 to "Syslog YANG Modules" since > it contains the definitions of the modules themselves. > > - In section 2, should 'monitor and control' be 'configure and > monitor' in section 2? Are there actually definitions that support > monitoring? Perhaps the scope is just configuration? Otherwise, I > would have expected to see a bunch of basic counters (messages > received, forwarded, dropped, the usual monitoring stuff). > > - In section 2, s/network management agents such as NETCONF/network > management protocols such as NETCONF/ > > - In section 2, the phrase 'This module' is a hanging reference. There > is no prior text talking about a module. Perhaps replace with 'The > data model' > > - I did not find the term 'message distributor' in RFC 5424. The > figure first made me assume that only a console, log buffers, or log > files are message distributors but later it was stated that relays > and collectors (RFC 5424 defined terms) are also 'message > distributors'. Perhaps it helps t
Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt
In ietf-syslog-types, there is a mapping of facility names to a limited number space on the wire. Unfortunately, this mapping is not available in a machine readable form. But for those names listed in RFC 5424, there is at least a mapping defined in human readable form in the description clauses. The examples given in A.1 are completely silent about which number is used on the wire. I think this is a problem if you consider setups where a relay is expected to filter on facility values. When an originator uses facility 'vendor:foo', what will that facility be from the viewpoint of a relay? /js On Thu, Jun 16, 2016 at 09:45:06PM +, Sterne, Jason (Nokia - CA) wrote: > Hi Juergen, > > About the identities vs enum for 'facilities' -> I'm pretty sure it was > discussed on the list previously but I think the applicability of the model > is going to be much better if we allow extensible facilities. Several > implementations use proprietary facility names along with RFC5424 facility > names in a unified way to configure logging. > > IMO this YANG model isn't exactly trying to match & reproduce RFC5424. > RFC5424 is more about the format of syslog messages on a wire. But this > syslog YANG model is more about how devices configure logging. > > So I'm strongly in favor of seeing the facilities stay as an identity. > > Regards, > Jason > > -Original Message- > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, June 15, 2016 11:30 > To: netmod@ietf.org > Subject: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt > > Hi, > > Dan Romascanu encouraged me to look at this I-D as part of his efforts to > organize YANG document reviews. Since the YANG definitions are not consistent > with the tree diagram, I have not really looked at the YANG definitions yet. > So the comments below are essentially about the surrounding document > structure, terminology, etc. > > - Abstract: The 'which is used to convey event notification messages' > may relate to 'the Syslog protocol' or 'a data model' and hence the > sentence is I think potentially confusing. Perhaps simply remove the > phrase altogether? Readers who do not know what SYSLOG is should > stop reading here anyway. Or break the sentence into two to make the > structure clearer. Perhaps add one more sentence describing what the > scope of the data model is. > > - The text uses Syslog, syslog, and SYSLOG. It is not clear what the > difference is (if any). If there is no semantic difference, I > suggest to pick one writing style (and 5424 seems to prefer all > lowercase except in cases where a sentence starts etc). > > - Change title of 4.1 to 'The ietf-syslog-types Module' and 4.2 > to 'The ietf-syslog Module' or something similar and consider > changing the title of section 4 to "Syslog YANG Modules" since > it contains the definitions of the modules themselves. > > - In section 2, should 'monitor and control' be 'configure and > monitor' in section 2? Are there actually definitions that support > monitoring? Perhaps the scope is just configuration? Otherwise, I > would have expected to see a bunch of basic counters (messages > received, forwarded, dropped, the usual monitoring stuff). > > - In section 2, s/network management agents such as NETCONF/network > management protocols such as NETCONF/ > > - In section 2, the phrase 'This module' is a hanging reference. There > is no prior text talking about a module. Perhaps replace with 'The > data model' > > - I did not find the term 'message distributor' in RFC 5424. The > figure first made me assume that only a console, log buffers, or log > files are message distributors but later it was stated that relays > and collectors (RFC 5424 defined terms) are also 'message > distributors'. Perhaps it helps to clearly spell out terms imported > from RFC 5424 and to clearly define any additional terms that go > beyond what is defined in RFC 5424. > > - Is it possible to shorten 'log-input-transports' to simply > 'log-inputs' (en par with log-actions)? And since both containers > are under syslog, perhaps even the 'log-' prefix is not needed and > all we have are /syslog/inputs and /syslog/actions? (I generally > find it useful to look at the resulting paths and whether they are > 'engineer friendly'. > > - I guess I have to define multiple /syslog/input/receiver in order to > listen on multiple UDP ports, e.g. to support both 0.0.0
Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt
Hi Juergen, About the identities vs enum for 'facilities' -> I'm pretty sure it was discussed on the list previously but I think the applicability of the model is going to be much better if we allow extensible facilities. Several implementations use proprietary facility names along with RFC5424 facility names in a unified way to configure logging. IMO this YANG model isn't exactly trying to match & reproduce RFC5424. RFC5424 is more about the format of syslog messages on a wire. But this syslog YANG model is more about how devices configure logging. So I'm strongly in favor of seeing the facilities stay as an identity. Regards, Jason -Original Message- From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, June 15, 2016 11:30 To: netmod@ietf.org Subject: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt Hi, Dan Romascanu encouraged me to look at this I-D as part of his efforts to organize YANG document reviews. Since the YANG definitions are not consistent with the tree diagram, I have not really looked at the YANG definitions yet. So the comments below are essentially about the surrounding document structure, terminology, etc. - Abstract: The 'which is used to convey event notification messages' may relate to 'the Syslog protocol' or 'a data model' and hence the sentence is I think potentially confusing. Perhaps simply remove the phrase altogether? Readers who do not know what SYSLOG is should stop reading here anyway. Or break the sentence into two to make the structure clearer. Perhaps add one more sentence describing what the scope of the data model is. - The text uses Syslog, syslog, and SYSLOG. It is not clear what the difference is (if any). If there is no semantic difference, I suggest to pick one writing style (and 5424 seems to prefer all lowercase except in cases where a sentence starts etc). - Change title of 4.1 to 'The ietf-syslog-types Module' and 4.2 to 'The ietf-syslog Module' or something similar and consider changing the title of section 4 to "Syslog YANG Modules" since it contains the definitions of the modules themselves. - In section 2, should 'monitor and control' be 'configure and monitor' in section 2? Are there actually definitions that support monitoring? Perhaps the scope is just configuration? Otherwise, I would have expected to see a bunch of basic counters (messages received, forwarded, dropped, the usual monitoring stuff). - In section 2, s/network management agents such as NETCONF/network management protocols such as NETCONF/ - In section 2, the phrase 'This module' is a hanging reference. There is no prior text talking about a module. Perhaps replace with 'The data model' - I did not find the term 'message distributor' in RFC 5424. The figure first made me assume that only a console, log buffers, or log files are message distributors but later it was stated that relays and collectors (RFC 5424 defined terms) are also 'message distributors'. Perhaps it helps to clearly spell out terms imported from RFC 5424 and to clearly define any additional terms that go beyond what is defined in RFC 5424. - Is it possible to shorten 'log-input-transports' to simply 'log-inputs' (en par with log-actions)? And since both containers are under syslog, perhaps even the 'log-' prefix is not needed and all we have are /syslog/inputs and /syslog/actions? (I generally find it useful to look at the resulting paths and whether they are 'engineer friendly'. - I guess I have to define multiple /syslog/input/receiver in order to listen on multiple UDP ports, e.g. to support both 0.0.0.0:514 and [::]:514? This may be just find - just checking that this is the idea. - I actually do not find the definition of log-input-transports in the YANG model. It seems the tree diagram is not consistent with the YANG model. So I can't judge what the structured-data boolean flag is doing or what the syslog-sign presence container would do for inputs. - The security considerations are quite generic; I think the template asks for a more specific discussion. - I am not sure why RFC 6020 is an informative reference and why all the normative references are actually normative. It might be useful to go over the list to make sure we get the normative / informative distinction right. - My understanding is that RFC 5424 numbers facilities and there is a hard limit on the number of facilities that the protocol can distinguish. RFC 5424 says: Facility values MUST be in the range of 0 to 23 inclusive. Given this, the 'extending facilities' appendix does not make much sense to me. And given the fact that the number of facilities
[netmod] partial review of draft-ietf-netmod-syslog-model-08.txt
Hi, Dan Romascanu encouraged me to look at this I-D as part of his efforts to organize YANG document reviews. Since the YANG definitions are not consistent with the tree diagram, I have not really looked at the YANG definitions yet. So the comments below are essentially about the surrounding document structure, terminology, etc. - Abstract: The 'which is used to convey event notification messages' may relate to 'the Syslog protocol' or 'a data model' and hence the sentence is I think potentially confusing. Perhaps simply remove the phrase altogether? Readers who do not know what SYSLOG is should stop reading here anyway. Or break the sentence into two to make the structure clearer. Perhaps add one more sentence describing what the scope of the data model is. - The text uses Syslog, syslog, and SYSLOG. It is not clear what the difference is (if any). If there is no semantic difference, I suggest to pick one writing style (and 5424 seems to prefer all lowercase except in cases where a sentence starts etc). - Change title of 4.1 to 'The ietf-syslog-types Module' and 4.2 to 'The ietf-syslog Module' or something similar and consider changing the title of section 4 to "Syslog YANG Modules" since it contains the definitions of the modules themselves. - In section 2, should 'monitor and control' be 'configure and monitor' in section 2? Are there actually definitions that support monitoring? Perhaps the scope is just configuration? Otherwise, I would have expected to see a bunch of basic counters (messages received, forwarded, dropped, the usual monitoring stuff). - In section 2, s/network management agents such as NETCONF/network management protocols such as NETCONF/ - In section 2, the phrase 'This module' is a hanging reference. There is no prior text talking about a module. Perhaps replace with 'The data model' - I did not find the term 'message distributor' in RFC 5424. The figure first made me assume that only a console, log buffers, or log files are message distributors but later it was stated that relays and collectors (RFC 5424 defined terms) are also 'message distributors'. Perhaps it helps to clearly spell out terms imported from RFC 5424 and to clearly define any additional terms that go beyond what is defined in RFC 5424. - Is it possible to shorten 'log-input-transports' to simply 'log-inputs' (en par with log-actions)? And since both containers are under syslog, perhaps even the 'log-' prefix is not needed and all we have are /syslog/inputs and /syslog/actions? (I generally find it useful to look at the resulting paths and whether they are 'engineer friendly'. - I guess I have to define multiple /syslog/input/receiver in order to listen on multiple UDP ports, e.g. to support both 0.0.0.0:514 and [::]:514? This may be just find - just checking that this is the idea. - I actually do not find the definition of log-input-transports in the YANG model. It seems the tree diagram is not consistent with the YANG model. So I can't judge what the structured-data boolean flag is doing or what the syslog-sign presence container would do for inputs. - The security considerations are quite generic; I think the template asks for a more specific discussion. - I am not sure why RFC 6020 is an informative reference and why all the normative references are actually normative. It might be useful to go over the list to make sure we get the normative / informative distinction right. - My understanding is that RFC 5424 numbers facilities and there is a hard limit on the number of facilities that the protocol can distinguish. RFC 5424 says: Facility values MUST be in the range of 0 to 23 inclusive. Given this, the 'extending facilities' appendix does not make much sense to me. And given the fact that the number of facilities is fixed (which is due to the way things are encoded in RFC 5424), I am not even sure that using an identity instead of an enumeration is useful (except if we expect a future version of SYSLOG to use a very different encoding of facilities). I mean, to stay within the bounds of RFC 5424, all one can do is to add an identity that maps to an already allocated code point. - Do not use 1.1.1.1 as an example IP address, consider using an IPv6 address from the IPv6 example address space. - Section 4.3 should not be in Section 4 and the title 'A Syslog Example' is kind of misleading since the text shows NETCONF messages operating on the SYSLOG YANG data model. I suggest to move 4.3 to a new top-level section 5 "Usage Examples". Does it make sense to show some complete example configs for typical use cases? - Before the YANG model definitions, it is a common idea to describe what is imported from which RFCs. For example, one of the YANG modules imports ietf-interfaces but there is no (normative) reference to the relevant RFC. See the first sentence in section 4 of RFC 72
