Thx Clyde. The analysis approach below is really useful - thx for putting that
together.
Given that Mahesh's comments about log-input were maybe meant for something
else we should reconsider the addition of that item. We aren't exactly trying
to model RFC5424 here (which is more of a protocol and data format document).
We're more trying to model how devices configure logging.
If it is purely a Linux Rsyslog thing then maybe it belongs in a separate
module that would be separately advertised. The whole Rx side of this is a
different beast IMO.
Other opinions on this one ?
Alcatel should probably be Nokia now :-)
Corrections to the Alcatel/Nokia column:
- Add an x in the log-action remote row
- feature buffer-limit-bytes is not supported
- feature buffer-limit-messages (from prev version of draft) is supported
- Add an x in the feature file-limit-duration row
- remove the x from the session-facility-user-logging row
So the updated table becomes this:
Feature Nokia Brocade Ciena Cisco IOS/XE Cisco IOS/XR
Cisco NXOS Juniper JunOS Linux Rsyslog Comments
log-input-transports
x
log-action console x x x x
x x x
log-action buffer x x x
log-action file x x x
x x x
log-action remote x x x x x
x x x
log-action terminal x x
x x
log-action session x
x
feature buffer-limit-bytes x x
feature buffer-limit-messages x
feature file-limit-size x x
x
feature file-limit-duration x x
x
feature
terminal-facility-device-logging
feature
session-facility-user-logging
x
feature select-sev-compare x x
x
feature select-match x x
x x
feature structured-data
x x Required because of RFC 5424
feature signed-messages
x Required because of RFC 5848
Based on that we could consider the following to simplify things:
- removing both buffer-limit-bytes and buffer-limit-messages and leave those to
augmentations (or even remove buffer all together from the model as an action)
- making select-match part of the base model without any if-feature
- remove feature session-facility-user-logging from the draft
- remove feature signed-messages from the draft
I'm not sure if the pyang tree fully matches the model in the doc. One example
-> the tree has select-sev-compare but the model itself below has
selector-sevop-config. I think I saw other differences when I was looking
around (select-match is another one).
Regards,
Jason
-----Original Message-----
From: Clyde Wildes (cwildes) [mailto:[email protected]]
Sent: Tuesday, May 31, 2016 16:54
To: Sterne, Jason (Nokia - CA); [email protected]
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt
Jason,
With regards to adding log-input-transports: please see RFC 5424 – The Syslog
Protocol, sections 3 and 4 where relay and collector functions are discussed.
In order to support the relay and/or collector function, log-input-transports
is required and I believe it is best to support the entire RFC 5424 protocol.
I produced the following table to help with the analysis of what features might
be included. Please provide updates to the table to help with the analysis.
Feature Alcatel Brocade Ciena Cisco IOS/XE Cisco IOS/XR
Cisco NXOS Juniper JunOS Linux Rsyslog Comments
log-input-transports
x
log-action console x x x x
x x x
log-action buffer x x x
log-action file x x x
x x x
log-action remote x x x x
x x x
log-action terminal x x
x x
log-action session x
x
feature buffer-limit-bytes ? x x
feature file-limit-size x x
x
feature file-limit-duration x
x
feature
terminal-facility-device-logging
feature
session-facility-user-logging x
x
feature select-sev-compare x x
x
feature select-match x x
x x
feature structured-data
x x Required because of RFC 5424
feature signed-messages
x Required because of RFC 5848
Alcatel -
https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/9300710702_V1_7750%20SR%20(SERVICE%20ROUTER).pdf
Ciena - https://www.commoncriteriaportal.org/files/epfiles/st_vid10460-st.pdf
Cisco IOS/XE -
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/esm/command/esm-cr-book/esm-cr-a1.html
Cisco IOS/XR -
http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/system_monitoring/command/reference/b-sysmon-cr-asr9k/b-sysmon-cr-asr9k_chapter_0100.html
Cisco NXOS -
http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus7000/sw/system-management/command/reference/n7k_sm_cmd_ref/sm_cmd_l.html#pgfId-1014686
Brocade -
http://www.brocade.com/content/html/en/command-reference-guide/nos-700-commandref/GUID-2297E4CA-76DC-43E5-9164-AC1AC9D3F4E7.html
Juniper JunOS -
http://www.juniper.net/documentation/en_US/junos12.3/topics/reference/configuration-statement/syslog-edit-system.htm;
Linux Rsyslog - http://www.rsyslog.com/doc/v8-stable/
Thanks,
Clyde
On 5/27/16, 12:30 PM, "Sterne, Jason (Nokia - CA)" <[email protected]>
wrote:
>Hi Clyde,
>
>I was a bit surprised to see the receiver/server side config in here
>(log-input-transports). That seems to be a somewhat significant change in
>scope. I thought the focus of this was more on the generation & distribution.
> Do many implementations have functionality that maps to this
>log-input-transports ? In any case the pyang tree has log-input-transports
>but it doesn't seem to be down in the actual model itself. But I'd be
>inclined to just remove this from the model. Maybe Mahesh has some thoughts
>here (I didn't see a posting about this in the mailing list).
>
>I agree there are multiple implementations of console, buffer and session
>logs. But maybe 'terminal' should be removed or an if-feature ? I'm not sure
>that one is so widespread (not in JUNOS, not in SR OS).
>
>Buffer-limit-messages and having multiple log buffers are both supported by
>Nokia SR OS. I would think that both of those would have support in other
>logging implementations as well. I'm not sure if Tom P. was really concluding
>that there are no implementations of these in his email. Do we have multiple
>examples of implementations that limit log buffers using bytes ?
>
>Buffer-limit-messages would be easy to do as an augmentation but making the
>log-buffer a list is probably something we should just do from the start.
>That is also consistent with all the other types of actions (except console of
>course). The use case for multiple log buffers is that you might sort/filter
>different types of log events into different circular buffers (i.e. have one
>for really critical log events, etc) for viewing on the node.
>
>Regards,
>Jason
>
>-----Original Message-----
>From: netmod [mailto:[email protected]] On Behalf Of EXT Clyde
>Wildes (cwildes)
>Sent: Tuesday, May 10, 2016 17:23
>To: [email protected]
>Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-08.txt
>
>Hi,
>
>This update to the draft-ietf-netmod-syslog-model-08 incorporates the changes
>listed below based on feedback received.
>
>An additional revision to this draft will be necessary to finalize TLS
>configuration leaves once the ietf-tls-client-server-model that the NETCONF WG
>plans to spin out of the netconf-server-model draft is available.
>
>Changes from feedback from Mahesh J:
>- added support for configuring a syslog server
>
>Changes from feedback from Tom P.:
>- removed four features for log action leaves console, buffer, terminal and
>session since they are implemented by multiple vendors. Lack of support for
>these actions can be indicated using a deviation.
>- removed feature buffer-limit-messages since implementation by any
>vendor is unknown
>- renamed feature terminal-facility-user-logging-config to
>terminal-facility-device-logging to shorten the name and to clarify
>- renamed feature session-facility-user-logging-config to
>session-facility-user-logging to shorten the name
>- renamed feature selector-sevop-config to feature select-sev-compare
>to shorten the name
>- renamed feature selector-match-config to feature select-match to
>shorten the name
>- renamed feature structured-data-config to feature structured-data to
>shorten the name
>- renamed feature signed-messages-config to feature signed-messages to
>shorten the name
>- removed the log-buffer list and name from log-action buffer since
>implementation by any vendor is unknown
>- removed the word draft from section 1
>- updated the copyright dates and the revision dates in the models
>- moved the example to an Appendix
>- removed e-mail addresses from the acknowledgement section
>
>Changes from feedback from Benoit:
>- rename module vendor-syslog-types to module
>vendor-syslog-types-example
>
>
>Thanks,
>
>Kiran and Clyde
>
>
>
>
>On 5/10/16, 2:14 PM, "netmod on behalf of [email protected]"
><[email protected] on behalf of [email protected]> wrote:
>
>>
>>A New Internet-Draft is available from the on-line Internet-Drafts
>>directories.
>>This draft is a work item of the NETCONF Data Modeling Language of the IETF.
>>
>> Title : SYSLOG YANG Model
>> Authors : Clyde Wildes
>> Kiran Koushik
>> Filename : draft-ietf-netmod-syslog-model-08.txt
>> Pages : 35
>> Date : 2016-05-10
>>
>>Abstract:
>> This document describes a data model for the Syslog protocol which is
>> used to convey event notification messages.
>>
>>
>>The IETF datatracker status page for this draft is:
>>https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/
>>
>>There's also a htmlized version available at:
>>https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-08
>>
>>A diff from the previous version is available at:
>>https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-08
>>
>>
>>Please note that it may take a couple of minutes from the time of
>>submission until the htmlized version and diff are available at
>>tools.ietf.org.
>>
>>Internet-Drafts are also available by anonymous FTP at:
>>ftp://ftp.ietf.org/internet-drafts/
>>
>>_______________________________________________
>>netmod mailing list
>>[email protected]
>>https://www.ietf.org/mailman/listinfo/netmod
>_______________________________________________
>netmod mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
