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

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Aug 2016 12:36:50 +0200

On Fri, Jul 08, 2016 at 10:37:06PM +0000, 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

           <actions>
             <console>
               <log-selector>
                 <log-facility>
                   <facility>all</facility>
                   <severity>critical</severity>
                 </log-facility>
               </log-selector>
             </console>
           </actions>

  into this
  
           <actions>
             <console>
               <selector>
                 <facility>
                   <name>all</name>
                   <severity>critical</severity>
                 </facility>
               </selector>
             </console>
           </actions>

  BTW, is the following valid?

           <actions>
             <console>
               <selector>
                 <facility>
                   <name>kern</name>
                   <severity>notice</severity>
		   <compare-op>equal</compare-op>
                 </facility>
                 <facility>
                   <name>kern</name>
                   <severity>debug</severity>
		   <compare-op>equal</compare-op>
                 </facility>
               </selector>
             </console>
           </actions>

  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 data, is it a
  reasonable default to remove structured data (default false of
  structured-data)?

  The model allows me to configure limits such as buffer-limit-bytes
  or buffer-limit-messages. Is there a way to obtain the system bounds
  for these limits (if there are any) or is the idea that applications
  determine the limits eventually via trial and error?

  Should 'uses selector;' always be immediately followed by 'uses
  structured-data;'? Sometimes there are other definitions in between,
  sometimes not. On some actions, the uses structured-data; is absent,
  is there any reason why this exists sometimes but not always?

  Is 'log file archiving' the right term? Is this not more commonly
  known as log file rotation? Archiving to me suggests that data is
  kept for a long period of time but log rotation usually only covers
  a couple of days.

  I am not sure I understand destination-facility which defaults to
  syslogtypes:local7. Can I not forward a syslog message to a remote
  destination without messing around with the facility?

  The source-interface description says an IP address can be specified
  which I think is not true (you use type if:interface-ref). I think
  what you are doing is right, the description likely needs an update.

  I suggest to a unit statements to cert-resend-delay, sig-max-delay,
  and sig-resend-delay.

* Editorial

  s/(5)as/(5) as/

  s/admisintrator/administrator/

  s/sprecific/specific/

/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/>