Hi Kent,
It's not the text, but the way the YANG model is organized v/s rsyslog
config+behaviour.
The YANG model is organized with collectors at the top. e.g. for remote
collectors we have a list of destinations, for each destination a facility-list
(keyed on facility + severity and ordered-by-user) and for each
facility+severity tuple we have an action: "block" or "log".
rsyslog config is not organized the same way as the YANG model: it first
matches on facility+severity and then the action is a "collector" (e.g.
destination or logfile) or "stop". "stop" is not the equivalent of "block":
once a "stop" is hit, the message is discarded. This means if other
destinations were meant to receive this message, they won't.
So translating/mapping the YANG model to rsyslog config is problematic when
"block" is used. As per previous disclaimer, I am no rsyslog expert. If there's
anyone who's managed to make it work....
And JTBC, I'm not saying the model is wrong since it probably matches how
many/most network OSes behave.
Regards,Reshad.
On Monday, October 31, 2022, 08:03:50 PM EDT, Kent Watsen
<kent+i...@watsen.net> wrote:
Reshad,
Which text in the draft are you pointing to?
Thanks,Kent // as Shepherd
On Oct 17, 2022, at 10:33 AM, Reshad Rahman <res...@yahoo.com> wrote:
Hi,
I believe this model is hard (impossible?) to implement with rsyslog since with
rsyslog as soon as a message is blocked/discarded, no further processing of
that message takes place (so other destinations won't get the message either).
I don't have a solution proposal, just an observation...
Disclaimer: I'm not a syslog expert and I have no idea what implementations out
there typically do.
Regards,Reshad.
On Tuesday, October 11, 2022, 01:11:26 PM EDT, Joe Clarke (jclarke)
<jclarke=40cisco....@dmarc.ietf.org> wrote:
This revision does a few things:
- Addresses comment from 114 to use
ct:asymmetric-key-pair-with-cert-grouping instead of
ct:asymmetric-key-pair-with-certs-grouping
- Fix Mahesh’s email
- Replace obsolete RFC references
- Adjust some line lengths
This passes YANG validation and IDNITS and addresses all known open comments.
We’d like to ask the chairs to conduct another WG LC for this work.
Joe
From: netmod <netmod-boun...@ietf.org> on behalf of internet-dra...@ietf.org
<internet-dra...@ietf.org>
Date: Tuesday, October 11, 2022 at 13:04
To: i-d-annou...@ietf.org <i-d-annou...@ietf.org>
Cc: netmod@ietf.org <netmod@ietf.org>
Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-28.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.
Title : A YANG Data Model for Syslog Configuration
Authors : Joe Clarke
Mahesh Jethanandani
Clyde Wildes
Kiran Koushik
Filename : draft-ietf-netmod-syslog-model-28.txt
Pages : 41
Date : 2022-10-11
Abstract:
This document defines a YANG data model for the configuration of a
syslog process. It is intended this model be used by vendors who
implement syslog in their systems.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-28
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-28
Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
