Re: [netmod] Syslog YANG Model Presentation

["Clyde Wildes (cwildes)" <[e-mail]>]

Juergen,

Thanks for your review.

My answers are inline as [clyde]...

On 7/22/14, 11:05 AM, "Juergen Schoenwaelder"
<[e-mail]> wrote:

>On Mon, Jul 21, 2014 at 09:16:16PM +0000, Clyde Wildes (cwildes) wrote:
>> 
>> The latest draft of the proposed Syslog YANG Model RFC is at:
>> 
>>http://www.ietf.org/internet-drafts/draft-wildes-netmod-syslog-model-02.t
>>xt
>> 
>
>The traditional Unix syslog daemons usually understand configuration
>rules like this:
>
>*.=info;*.=notice;*.=warn;\
>	auth,authpriv.none;\
>        cron,daemon.none;\
>        mail,news.none          -/var/log/messages
>
>That is, you have rules with multiple selectors that lead to a certain
>action. Note also the various wildcards above. You seem to model this
>backwards, that is the action first followed by the selectors - why?
>I think using the terminology of 'selectors' and 'actions' is quite
>common in Unix syslog land - perhaps this should be adopted instead of
>'Message Distributors' and related terms. It seems some syslog
>implementations (e.g. rsyslog) have a more general concept of a filter
>and selectors (matching facility/severity) and just one of several
>ways to filter.
>
>/js

[clyde] We examined five vendor OSs¹ syslog configuration when we
developed this draft (Brocade, Cisco IOS/XR Cisco IOS/XR, Cisco NXOS, and
Juniper JunOS). We did not consider Unix syslog configuration. In
hindsight we should have and will support it in a future version.

Some vendors support multiple selectors for a specific action and that is
included in this draft.

Treating actions as high level leaves in the model makes it easier to
augment an action IMHO.

Items missing from this draft that are Unix like are:
1. the mark facility - the current model does not support the ³mark"
facility which is a Linux method where messages generated by syslogd
itself that contain only a timestamp and the string ³‹MARK-" are selected
when the ³mark" facility is specified. If needed this could be added by
augmenting the syslog-facility identity in ietf-syslog-types.yang.
2. priority support - the current model does not support:
   - the * specification for all priorities (although specifying ³debug"
means the same thing since specification for priority mean any message
with priority less than or equal to the specified priority is passed and
debug is the highest number of 7),
   - the = specification for a specific priority, or != for any priority
but the specified priority.
3. evaluation of multiple selectors - although we allow multiple
facility/priority selectors for an action we do not follow the linux rule
that says that when an action contains multiple selectors, they are
evaluated from left to right (first to last); The UNIX pattern is that you
list general selectors first, followed by more specific selectors because
once a selector pattern is met, no further selectors are processed for
that action.


>
>PS: I think you should also refer to the standards-track version of
>    SYSLOG (RFC 5424) in the references and perhaps filters should
>    also be able to operate on structured content.

[clyde] I agree that RFC 5424 should be referenced and will include this
in a future revision. Only one vendor has implemented delivery of
structured syslog messages and so we left this for augmentation. We also
left message filtering by message text pattern matching for augmentation.

>
>PS: I do not really understand 'global logging'.

[clyde] Some vendors include an extra log message suppression mechanism
that is logically before the selectors/actions mechanism. We called this
mechanism ³global-logging². It is listed as a feature for those vendors
that support it and it is described in the RFC document.

>
>PS: A configuration model should probably also include ways to
>    configure on which endpoints the syslog 'daemon' is receiving
>    input.

[clyde] This model does not include syslogd daemon listener configuration
(the daemon listens for syslog messages on port 514 on all interfaces if
the ³-r² switch is included on the syslogd command line). I am thinking
that syslog daemon configuration should be a separate model since this
model is concerned with syslog message distribution. For reference here is
the FreeBSD syslogd man page which shows the many syslogd daemon options:
http://www.freebsd.org/cgi/man.cgi?query=syslogd&sektion=8

>
>PS: The reference in the revision statement is usually used to refer
>    to the document defining that specific revision of the data model.
>
>PS: For the example, simple show the config instance not the NETCONF
>    exchange.

[clyde] Please explain. Should the reference for revision 02 be to:
        http://tools.ietf.org/html/draft-wildes-netmod-syslog-model-02

The current revision 03 contents are:

 revision 2014-06-10 {
   description
     "Initial revision.";
   reference
     "This model references RFC 5424 - The Syslog Protocol.";
  }

Thanks,

Clyde

>
>-- 
>Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
>Fax:   [phone]         <http://www.jacobs-university.de/>