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

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Mon, 31 Oct 2016 20:22:45 +0000

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" <[email-masked]> wrote:

    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)?

[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 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>
    
[clyde] Adopted.

      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

[clyde] Yes this is valid if the target implementation supports the feature “elect-sev-compare”.
    
      If my syslog implementation supports structured data, is it a
      reasonable default to remove structured data (default false of
      structured-data)?

[clyde] Since structured data is chosen on a collector by collector basis I am not sure
what you are asking. Please remember that some remote collectors may not support 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?

[clyde] In a prior revision I was asked to use the phrase “The default value 
varies by implementation” since there is no RPC available to obtain the limits for
a specific implementation.
    
      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?

[clyde] I have moved the 'uses structured-data;' to always be behind
‘uses selector’.
    
      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.

[clyde] I changed to “container file-rotation” and “log file rotation.”
    
      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?

[clyde] Some vendors allow a facility override which, when specified, overrides the 
facility for all messages sent to the remote collector. Example:
http://www.juniper.net/documentation/en_US/junos15.1/topics/reference/configuration-statement/facility-override-edit-system.html

I have restructured this field to become:
          leaf facility-override {
            type identityref {
              base syslogtypes:syslog-facility;
            }
            description
              "If specified, this leaf specifies the facility used 
               to override the facility in messages delivered to the 
               remote server.";
          }

      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.

[clyde] I have updated the description to be:

            description
              "This leaf sets the source interface to be used to send 
               message to the remote syslog server. If not set, 
               messages sent to a remote syslog server will 
               contain the IP address of the interface the syslog 
               message uses to exit the network element";

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

[clyde] Adopted.
    
    * Editorial
    
      s/(5)as/(5) as/
    
      s/admisintrator/administrator/
    
      s/sprecific/specific/

[clyde} Adopted.
    
    /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/>