Hi Joe, Kent,
I think adding a "stop" action would indeed help and yes identities is a good 
idea.
Regards,Reshad.
    On Friday, January 13, 2023, 09:22:41 AM EST, Joe Clarke (jclarke) 
<[email protected]> wrote:  
 
 
One thing I was kicking around with Mahesh is a compromise on Reshad’s problem 
by adding a “stop” action.  It won’t address the organization of the 
destination, but it would allow for one to express this semantic.  Moreover, 
the actions could be turned into identities (instead of an enum) to allow for 
future extensibility here.
 
  
 
What does the WG think of these options (now that we’re in another LC)?
 
  
 
Joe
 
  
 
From: Kent Watsen <[email protected]>
Date: Friday, January 13, 2023 at 07:58
To: Reshad Rahman <[email protected]>
Cc: [email protected] <[email protected]>, Joe Clarke (jclarke) <[email protected]>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-28.txt
 
Hi Reshad,
 
  
 
Thank you for explaining.   I share your assessment that it the model may not 
be implementable in rsyslog.  I also cannot fault the model nor advocate a 
change.  It is unknown to me how pervasive the issue may be, but the model did 
go thru a WGLC before, which would've been the time for the various "network 
OS" vendors to flag issues.  Furthermore, there has been no uproar following 
your message below, in fact, I'm the first to respond.  Based on this, my 
assessment (as both Shepherd and Chair) is to proceed the document now.
 
  
 
Kent
 
  
 



 

On Nov 2, 2022, at 3:35 PM, Reshad Rahman <[email protected]> wrote:
 
  
 
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 
<[email protected]> 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 <[email protected]> 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) 
<[email protected]> 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 <[email protected]> on behalf of [email protected] 
<[email protected]>
Date: Tuesday, October 11, 2022 at 13:04
To: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
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
[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

Reply via email to