Re: [netmod] Syslog YANG Model Presentation

[Benoit Claise <[e-mail]>]

Hi Chris,
> Hi Benoit and all,
>
> I'm not exactly sure what you're asking.  I agree with Rainer that the 
> ID is well written.
>
> I am not subscribed to the mailing list and have not been following 
> the discussions so please take my comments with a grain of salt.  :-)
>
> If you're asking if draft-wildes-netmod-syslog-model needs to be 
> expanded to include the available options resulting from the IETF work 
> on syslog (which is more than 5424, 5425, and 5426), then I would say 
> that it does not.  It looks to me (I'm not overly familiar with Yang) 
> that what is described in the ID is equivalent to what can be defined 
> in a current syslog.conf configuration.  IMHO, that should be good 
> enough at this time to publish the document as an informational RFC 
> (as it's classified now).
This was actually my question. Thanks.
>
> If you're asking if a potential draft-ietf-netmod-syslog-model 
> (standards track) should be more thorough to include the available 
> options resulting from the IETF work on syslog, then I'll give a 
> definite "maybe".  :-)  There doesn't appear to be anything in 
> draft-wildes... that conflicts with the syslog HEADER in 5424; 
> therefore, it should just work.  The Structured-Data is used in the 
> PAYLOAD and that can't be configured.  What would be missing in the 
> configuration is the specification of the transport.  You mention 5425 
> and 5426, but there are others:
> 5425 - TLS (recommended)
> 5426 - UDP (not so much recommended but greatly in use)
> 6012 - DTLS
> 6587 - TCP (the IESG said to NOT use this, but it is in use :-)
> If the document were to be expanded, it would need to include some 
> very complex rules.  For example:
>  - Facilities 4 and 10 with severities (0-6) send to 
> sec-logger.example.com <http://sec-logger.example.com> via 5425
>  - Facility 2 with severities (0-3) send to mail-logger.example.com 
> <http://mail-logger.example.com> via 5426
>  - All Facilities with severities (0-2) send to 
> central-logger.example.com <http://central-logger.example.com> via 6012
> As far as I know, the specification of the transport cannot currently 
> be configured in generic syslog.conf configurations.  I believe that 
> the implementations that are using something other than UDP are doing 
> it on a "one off" basis.  So, IMHO, trying to force that into a 
> standards track document shouldn't be done at this time.
Ok
>
> If you _are_ looking for draft-ietf-netmod-syslog-model, I would 
> suggest using draft-wildes... and add something about assuming that 
> the selection of a transport is implementation specific at this time, 
> and that a future revision of the model may include the option to 
> specify the transport(s).
Ok.
>
> And just since I'm going on and on (and on...), the syslog WG did not 
> complete a MIB on syslog.  If anyone is interested, we left off here:
> http://tools.ietf.org/html/draft-ietf-syslog-device-mib-17
>
> Just a nit to the authors, the last sentence of page 3 reads:
> Optional features are used to specified fields that are not present in
>     all vendor configurations.
> Perhaps s/specified/specify (but honestly I think that the sentence needs to be rewritten).
>
> And, if I'm totally off base on what you're asking, then please disregard.  :-)
This is exactly what I wanted to find out.

Regards, Benoit
>
> Best regards,
> Chris
>
> On Wed, Sep 10, 2014 at 2:21 AM, Benoit Claise <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Dear all,
>
>     As I understand, the conclusion from this email thread is that the
>     syslog YANG model must support the options for RFC 5424, RFC 5425,
>     and RFC 5426
>
>     Regards, Benoit
>>     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) <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         Benoit,
>>           We (GE MDS) support 5424/5425/5426 structured messages on
>>         our products (with vendor specific structured-data).
>>
>>         -Jeff Lange
>>
>>
>>
>>         From: Benoit Claise <[e-mail]
>>         <mailto:[e-mail]><mailto:[e-mail]
>>         <mailto:[e-mail]>>>
>>         Date: Wednesday, July 30, 2014 at 11:21 AM
>>         To: Jeffrey Haas <[e-mail]
>>         <mailto:[e-mail]><mailto:[e-mail]
>>         <mailto:[e-mail]>>>
>>         Cc: "[e-mail]
>>         <mailto:[e-mail]><mailto:[e-mail]
>>         <mailto:[e-mail]>>" <[e-mail]
>>         <mailto:[e-mail]><mailto:[e-mail]
>>         <mailto:[e-mail]>>>, Kiran Agrahara Sreenivasa
>>         <[e-mail]
>>         <mailto:[e-mail]><mailto:[e-mail]
>>         <mailto:[e-mail]>>>, "[e-mail]
>>         <mailto:[e-mail]><mailto:[e-mail]
>>         <mailto:[e-mail]>>" <[e-mail]
>>         <mailto:[e-mail]><mailto:[e-mail]
>>         <mailto:[e-mail]>>>, "[e-mail]
>>         <mailto:[e-mail]><mailto:[e-mail]
>>         <mailto:[e-mail]>>" <[e-mail]
>>         <mailto:[e-mail]><mailto:[e-mail]
>>         <mailto:[e-mail]>>>
>>         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,
>>
>>         On Tue, Jul 22, 2014 at 01:34:11PM -0400, Benoit Claise wrote:
>>
>>
>>         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.
>>
>>
>>         Is RFC 5424 actually deployed?
>>
>>
>>         Juniper has supported it for years.
>>
>>         -- Jeff
>>         .
>>
>>
>>
>>
>
>