Hi Chris,
I will submit an update of my proposal later. Before that, I would like anyone here to discuss what changes I need to make to merge Rainer and Tom's draft, that I can write in my new revision. I recalled that I wrote a mail before to review Rainer and Tom's draft, I asked some questions and can be concluded as below: 1. If it is necessary for "a syslog server should be a DTLS client"? 2. If we need ask different "registered port number" for DTLS different transport mapping (udp/sctp...) ? 3. If we need consistent syslog/dtls commands with syslog/tls ? 4. Anything else I need to cover from that covered in Rainer and Tom's ? I will update my proposal according to the consensus of discussions on these items. and at the time, I welcome any comments on my proposal, thanks. The original mail I list here for your information. -----Original Message----- Date: Sun, 12 Apr 2009 00:20:28 +0800 From: fenghongyan <[email protected]> Subject: [Syslog] Review of draft-petch-gerhards-syslog-transport-dtls-01.txt" To: [email protected] Message-ID: <[email protected]> Content-Type: text/plain; charset=us-ascii Hi, I read this proposal "draft-petch-gerhards-syslog-transport-dtls-01", I have some comments on it: Those changes I made in my new version this draft is also need to make, I think. section 1.3 The security discussion is similar as stated in syslog/tls, Pasi recommended simply pointer to syslog/tls would be better. section 1.4 This is covered in syslog/tls; a pointer to that document would work. section 2.1 I don't see if there's a necessary for a syslog server should be a DTLS client. In my understanding, a dtls request is alway initiate by a dtls client, if syslog server being dtls client, how does a server know which client want to connect to it? I think RFC5425 has state authentication in very detail and come up the corresponding security policy. Also, fingerprint is aim to cover the case you discussed in your draft having a certificate url authentication. A pointer to that document would work. section 2.2 I think a udp "registered port number" is required to assign for udp mapping and a sctp "registered port number" is required to assign for sctp mapping respectively. section 2.3 I claimed in my proposal to minimize the operation and security where both syslog/tls and syslog/dtls are supported, why do you need write the commands in your proposal? section 2.6, section 2.8 It is covered in syslog/tls security policy; a pointer to that document would work. Thanks Linda > > Message: 1 > Date: Mon, 1 Jun 2009 13:02:38 -0700 (PDT) > From: Chris Lonvick <[email protected]> > Subject: [Syslog] syslog WG Rechartering Discussion > To: [email protected] > Message-ID: <[email protected]> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > Hi Folks, > > David and I are going to open the discussion about rechartering. > Below > are some ideas that we've seen on the list that may fit into a > charter for > a new syslog Working Group. These seem to fit better in the > Operations > and Management Area than in the Security Area so we are asking the > ADs to > move the WG to there when we do recharter. > > We'd like to get the discussion started now on this mailing list and > have > a WG meeting in Stockholm to discuss rechartering issues. We hope > that by > having a real meeting, we can draw in more OPS people who are willing > to > work on these items, and/or to craft additional goals for syslog. > > Please send your comments in about this and help move syslog forward. > > > > Fundamentals > - Documenting how a syslog relay is supposed to work. RFC3164 says > that a > relay MAY change the header information in a syslog message. This > needs > to be reexamined since syslog-sign mandates that no changes are allowed > in the whole syslog message between the sender and the device that > validates the detached signatures. > - A DHC option for a syslog receiver. Write an ID that standardizes how > DHCP should specify a syslog server and associated transport (udp, > tls, > beep) in a URI format. > - The OpSec WG was planning to develop a draft about log event taxonomy > (what to log). This work should be compared to the syslog-alarm draft > from Sharon and Rainer, which defines categories for the alarm > that are > fairly consistent with the ALARM-MIB and ITU alarm categories. > There is > also CEE work that is also trying to define catagories of what to > log. > > > Architecture > - An informational document that describes how each of the header fields > should be used. The technical information is in RFC 5424 but > could use > some further explanation. > - Possibly combined with the previous topic, a "practical usage guide" > would be a good document for implementors and coders. > - A relook at the PRI values. There are currently 7 Severity levels > and > 21 Facilities. The Facilities are ill-defined and out of date. The > information there could be better described in SDEs. We kept the > historical PRI values so that we would have a smooth(er) > transition from > historical syslog to the IETF standard syslog. That has worked as > current syslog receivers do receive syslog messages in the new format. > > > Transport > - Documenting a TCP transport for syslog. There are many implementations > in the wild right now with two major variants. The problem > between them > is the delimiter; prevalently a CR (I believe) is used to separate > multiple messages within a single TCP packet. The minor-use > implementation does not have a delimiter and just assumes one message > per packet. This will be relatively easy to straighten out. > - Finish syslog-transport-dtls. There are two individual submissions > which may be combined and moved into the WG. > - We should do something with syslog/BEEP. Should we declare the current > syslog/BEEP historic? and/or should we start an effort to publish > an > update? > > > Ancillary > - There are other documents in the OPSAWG which might be better reviewed > in the new syslog WG, if they have not already completed reviews > elsewhere: > - Alarms in SYSLOG > - Mapping Simple Network Management Protocol (SNMP) Notifications > to > SYSLOG Messages > - Definitions of Managed Objects for Mapping SYSLOG Messages to Simple > Network Management Protocol (SNMP) Notifications > - It would be good to encourage other groups to bring drafts of Structured > Data implementations to Syslog WG for review. These would likely > not be > Syslog WG documents but the documents would benefit from being reviewed > by the Syslog WG. > - draft-fan-syslog-sending-policy-01 (Syslog Discard Messages) create > SDEs to report that a series of messages have been dropped by > a > sender. This document defines special syslog messages called > Discard messages for carrying logs loss statistics which indicate > how many logs (in terms of facility level or/and severity level) > were discarded by the syslog sender before they had a chance > to hit > the wire connected to the syslog receiver during a particular > period > in an extreme case. The statistics information Disard messages > convey is of interest to syslog receivers and helpful for > later on > audit. > - draft-dulaunoy-syslog-geolocation-00 proposes adding > geographic meta > information to syslog messages. This might be done using SDEs > - In an earlier version of netconf, there was work to correlate between > the information models of alarms from different NM interfaces. > Part of > the purpose was to ease correlation of event reports for the same > event > via different NM interfaces. > - Benoit Claise proposed making ipfix a general purpose reporting > protocol. Such a protocol might replace or supplement syslog. There > may be benefit to utilizing ipfix for carrying syslog information, > so > there might be benefit to defining a way to convert syslog content > into > ipfix formats, or to modify ipfix PDUs to carry syslog formats > (both the > human-readable message part and the SDEs). This was a brand new > proposal at IETF 74, so has not had much discussion yet. We can discuss > this to see if there would be interest in such a direction. > > > Thanks, > Chris & David > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
