Subject: [netmod] Syslog YANG Model Presentation

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Mon, 21 Jul 2014 21:16:16 +0000

Hi,

Please check out the Syslog YANG Model presentation that I was unable to
give this morning due to time constraints at:
http://tools.ietf.org/agenda/90/slides/slides-90-netmod-6.pdf

My narrative is that in a relatively short time Kiran Koushshik (Brocade)
and I were able to collaborate on a Syslog YANG model that covers common
Syslog configuration for Brocade¹s OS, Cisco IOS/XE, Cisco IOS/XR,
Cisco/NXOS, and Juniper¹s JunOS. The model consists of a group suppression
leaf, and four distributions leaves for: console, file, remote server, and
terminal/user. The model was designed to be augmented for OS specific
features, and the model has been implemented on Cisco¹s NXOS with an
augmentation model for OS specific features. We attended the YANG Drs¹
session on Sunday and received valuable feedback from Bert Wijnen, from
RIPE. Thanks Bert!

The latest draft of the proposed Syslog YANG Model RFC is at:
http://www.ietf.org/internet-drafts/draft-wildes-netmod-syslog-model-02.txt

Your review and comments would be appreciated.

Thanks,

Clyde

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Jul 2014 17:05:55 +0200

> http://www.ietf.org/internet-drafts/draft-wildes-netmod-syslog-model-02.txt

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

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.

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

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

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.

-- 
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: Benoit Claise <[email-masked]>
Date: Tue, 22 Jul 2014 13:34:11 -0400

>      also be able to operate on structured content.
Is RFC 5424 actually deployed?

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Jul 2014 20:03:50 +0200

> Is RFC 5424 actually deployed?

Are you suggesting that we write a configuration data model for a non
standards-track SYSLOG protocol even though there is a standards-track
SYSLOG protocol?

I think Debian system come with rsyslog these days (and I think the
same is true for Ubuntu). As far as I can tell, rsyslog supports RFC
5424 and if this is correct, RFC 5424 got at least 'fielded'. I can't
say how much structured data is used (if that is your question).

/js

---

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Wed, 23 Jul 2014 20:40:11 +0000

Juergen,

Thanks for your review.

My answers are inline as [clyde]...

>and selectors (matching facility/severity) and just one of several

[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.

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

>    configure on which endpoints the syslog 'daemon' is receiving

[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: For the example, simple show the config instance not the NETCONF

[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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 24 Jul 2014 00:03:33 +0200

> that support it and it is described in the RFC document.

If this is a global filter, it should probably have a name that makes
this clearer. But then, the I-D also says:

  feature global-logging {
    description
      "This feature represents the ability to adjust
       log message severity per logging facility on the
       global level.";
  }

This says 'adjust severity' which is again different from suppression
or filtering. The data model uses the facility-logging grouping, which
then again reads as a filter. In other words, it seems like messages
not passing 'global-logging' will be dropped. If this is the
intention, please make sure this is clearly described.

> http://www.freebsd.org/cgi/man.cgi?query=syslogd&sektion=8

Listener configuration could be left out or it could be made a
feature; most open source syslog daemons can listen for incoming
messages.

>      "This model references RFC 5424 - The Syslog Protocol.";

The idea is to refer to the document defining the YANG module, e.g.:

     // RFC Ed.: update the date below with the date of RFC publication
     // and remove this note.
     revision 2014-06-10 {
       description
         "Initial revision.";
       reference
         "RFC XXXX: A YANG Data Model for SYSLOG";
     }

This way, someone who has the YANG module can easily find the RFC
defining it.

/js

---

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Wed, 23 Jul 2014 22:38:05 +0000

Juergen,

We will update the description for global-logging to be clear.

We will consider adding syslog listener configuration as a feature.

We will update the reference section in the model as you described.

Thanks,

Clyde

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 30 Jul 2014 10:58:56 -0400

Benoit,

> Is RFC 5424 actually deployed?

Juniper has supported it for years.

-- Jeff

---

From: Benoit Claise <[email-masked]>
Date: Wed, 30 Jul 2014 17:21:57 +0200

Jeff,

Thanks.
So I guess we need to support RFC 5424, RFC 5425, and RFC 5426 
configuration in the YANG model, right?
You use only vendor specific STRUCTURED-DATA? Because I don't see many 
in theIANA registry 
<http://www.iana.org/assignments/syslog-parameters/syslog-parameters.xhtml#syslog-parameters-4>, 
and http://tools.ietf.org/html/rfc5424#section-9.2 requests IANA 
registration.

If my memory serves me well (I copied a couple of old timers), the 
STRUCTURED-DATA goal was to standardize the syslog message content in 
the industry, but that did not happen.

Regards, Benoit
> .

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 30 Jul 2014 11:31:07 -0400

Benoit,

> configuration in the YANG model, right?

Digging through my work archives, I appear to be speaking over-broadly.  We
have support for the structured syslog, but don't seem to have TLS support.

> You use only vendor specific STRUCTURED-DATA? Because I don't see
> many in theIANA registry <http://www.iana.org/assignments/syslog-parameters/syslog-parameters.xhtml#syslog-parameters-4>,

Correct, vendor specific.

> STRUCTURED-DATA goal was to standardize the syslog message content
> in the industry, but that did not happen.

One of the bits of discussion in I2RS was "use RFC 5424" as part of the
traceability requirements.  I tend to agree that it isn't widely deployed
and not heavily used when it is deployed.  

If I were an operator that was wanting to consume this state rather than a
vendor adding more logging, I'd prefer that it be something a bit more
nicely structured in an easy to parse sense.  The 5424 extensions get about
90% of the way there.  The last 10% would provide for actual nested data
rather than simple key-value mappings.

That, however, is a topic for another list.

-- Jeff

---

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Thu, 31 Jul 2014 13:19:04 +0000

Benoit,
  We (GE MDS) support 5424/5425/5426 structured messages on our products (with vendor specific structured-data).

-Jeff Lange

From: Benoit Claise <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 30, 2014 at 11:21 AM
To: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Kiran Agrahara Sreenivasa <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] Syslog YANG Model Presentation

Jeff,

Thanks.
So I guess we need to support RFC 5424, RFC 5425, and RFC 5426 configuration in the YANG model, right?
You use only vendor specific STRUCTURED-DATA? Because I don't see many in the IANA registry<http://www.iana.org/assignments/syslog-parameters/syslog-parameters.xhtml#syslog-parameters-4>, and http://tools.ietf.org/html/rfc5424#section-9.2 requests IANA registration.

If my memory serves me well (I copied a couple of old timers), the STRUCTURED-DATA goal was to standardize the syslog message content in the industry, but that did not happen.

Regards, Benoit

Benoit,

-- Jeff
.

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 31 Jul 2014 11:36:13 -0700

Hi,
The very brief background:
- the syslog WG was chartered under the Security Area to secure the protocol
- the BEEP work never took off so we rechartered and found that we needed
to make changes to the protocol itself
- in making the changes, Rainer Gerhards proposed structured data and the
WG liked that
- 5424 makes use of structured data but there are few implementations that
strictly adhere to the changes made to the packet header

On the other hand, everyone likes structured data and I've seen it used in
many places.  As far as I know, there have been no efforts to standardize
structured data but people are using it in many places because it is very
versatile and efficient, and it gets the job done.  :-)

I've been working (off and on and hopefully more 'on' soon) on an ID that
explains how non-standardized messages have been conveyed in
IETF-documented protocols.  It will need a couple of more revisions before
it's ready for consideration for publication but you may get some ideas
from it.
  https://datatracker.ietf.org/doc/draft-lonvick-private-tax/?include_text=1

Best regards,
Chris

On Thu, Jul 31, 2014 at 6:19 AM, Lange, Jeffrey K (GE Energy Management) <
[email-masked]> wrote:

> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>>, Kiran Agrahara Sreenivasa
> <[email-masked]<mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "
> [email-masked]<mailto:[email-masked]>" <
> [email-masked]<mailto:[email-masked]>>
> You use only vendor specific STRUCTURED-DATA? Because I don't see many in
> the IANA registry<
> http://www.iana.org/assignments/syslog-parameters/syslog-parameters.xhtml#syslog-parameters-4>,
> STRUCTURED-DATA goal was to standardize the syslog message content in the
> industry, but that did not happen.
>
> Regards, Benoit
>
> Benoit,
>