Re: [netmod] Syslog YANG Model Presentation

[Chris Lonvick <[e-mail]>]

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

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
via 5425
 - Facility 2 with severities (0-3) send to mail-logger.example.com via 5426
 - All Facilities with severities (0-2) send to 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.

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

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


Best regards,

Chris


On Wed, Sep 10, 2014 at 2:21 AM, Benoit Claise <[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]> 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]>>
>> Date: Wednesday, July 30, 2014 at 11:21 AM
>> To: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>
>> Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]
>> <mailto:[e-mail]>>, Kiran Agrahara Sreenivasa <
>> [e-mail]<mailto:[e-mail]>>, "[e-mail]
>> <mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "
>> [e-mail]<mailto:[e-mail]>" <
>> [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
>> .
>>
>>
>>
>>
>
>