> On Sep 9, 2024, at 6:28 PM, Paul Wouters via Datatracker <nore...@ietf.org> > wrote: > > Paul Wouters has entered the following ballot position for > draft-ietf-netmod-syslog-model-32: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for this document. I have a few points to discuss that hopefully are > minor and a result from my misunderstanding. > > The layout is completely broken / wrapped, making the document fairly > unreadable. Can this be fixed somehow ? > > I don't see a method for syslog using TCP without TLS ? In fact, I am using > that on my personal home router to my collection server, without TLS. Could > the > document not simply use: > > +--rw (transport) > | +--:(udp) > | | +--rw udp > | | +--rw address? inet:host > | | +--rw port? inet:port-number > | | +--rw tcp > | | +--rw address? inet:host > | | +--rw port? inet:port-number > | +--:(tls)
Good point. I have added a “tcp” option to transport, that will allow a user to configure syslog with TCP. > > Also, how do ports and addresses combine. Can I specify "1.2.3.4:80 and > 5.6.7.8:443" ? It looks like that is not the case here? That is correct. As defined, the model only allowed for one remote collector to be configured. I have changed it to a list, which should allow you to configure 1.2.3.4:80 4.5.6.7:80 Note, however, that a user cannot do is something like: 1.2.3.4:80 4.5.6.7:443 meaning configure a TCP session and a TLS based session at the same time. If such a flexibly is desired, we will have to drop the need to select a transport before configuring the remote address/port. > > I don't see an option for configuring ratelimits, which are commonly available > as options for syslog services? The WG made a conscious decision to support RFC 5424 features only, leaving out features such as rate limit supported by Rsyslog and Syslog-NG. > > Could the TLS configuration parameters not use another model (one the IESG > reviewed a little while ago?). It seems odd to define these within the syslog > module. It would be nice if any kind of certificate options with TLS could be > included from another module so if there are no TLS options, this module/RFC > does not require updating? As Joe explained, the model does include the definitions of TLS from RFC-to-be-9645 that IESG recently approved, and the reason this draft has stalled for so many years. > > Maybe the same applies for the "signers" section but perhaps that is > differently formatted data signed and unrelated to the TLS layer ? The signers sections uses the groupings defined in RFC-to-be-9640. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Related question: Is it one certificate+key that used for the TLS connection > as > well as to sign data within the payload of packets? I am not a TLS expert, but the certificate+key is used to establish a TLS session. Once the TLS session is established, both the client and server agree on symmetric session key for encrypting the payload. > > facility-filter seems badly named as it also filters for severity ? Maybe > syslof-filter ? Changed facility-filter to syslog-filter. Thanks > > > Mahesh Jethanandani mjethanand...@gmail.com
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
