Subject: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 15 Jun 2016 17:29:32 +0200

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 7277 for an example how to do this.

- I suggest to remove the subsection title 3.1. or to change the title
  to "SYSLOG Data Model" and lifting it up to the top-level so that it
  becomes section 4.

As said above, I have not reviewed the YANG definitions yet since
apparently it is not in sync with the rest of the document. But I
thought I send these comments now anyway so that they can already be
taken into account.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Thu, 16 Jun 2016 21:45:06 +0000

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:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, June 15, 2016 11:30
To: [email-masked]
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.

As said above, I have not reviewed the YANG definitions yet since apparently it is not in sync with the rest of the document. But I thought I send these comments now anyway so that they can already be taken into account.

/js

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Jun 2016 08:38:26 +0200

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

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Fri, 17 Jun 2016 13:34:31 +0000

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:[email-masked]] 
Sent: Friday, June 17, 2016 2:38
To: Sterne, Jason (Nokia - CA)
Cc: [email-masked]
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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Jun 2016 18:09:29 +0200

Then this probably needs to be more clearly spelled out.

/js

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Tue, 21 Jun 2016 21:28:21 +0000

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:[email-masked]] 
Sent: Friday, June 17, 2016 12:09
To: Sterne, Jason (Nokia - CA)
Cc: [email-masked]
Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.txt

/js

On Fri, Jun 17, 2016 at 01:34:31PM +0000, Sterne, Jason (Nokia - CA) wrote:
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Jun 2016 10:03:52 +0200

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