Re: [Syslog] #5 - character encoding (was: Consensus?)
Rainer I think I detect an approach I do not agree with, in this and perhaps other issues. You seem to be saying that the (eg POSIX) syslogd must emit perfect syslog messages and is responsible for anything that is wrong with them no matter what it received from the application (I exaggerate slightly). I would say that if the application passes incomprehensible garbage, something criminal or illegal, then it is the application that is at fault; syslogd can only be held responsible if it produces messages that are invalid for the parts over which it has control, eg header syntax. So if syslogd has no idea what the transfer encoding is because the rest of the system does not tell it, then syslogd cannot be held responsible for the absence of a field saying what the transfer encoding actually is. Or put differently, if our RFC specify what the application MUST or SHOULD do, as well as syslogd, then that is ok with me. What syslogd would be responsible for, IMO, would be allowing characters that have a special meaning in the syntax (eg NUL is end of message) appearing unescaped (or otherwise encoded). Whether we have such problems depends on the resolution of other issues, not saying that we have at present. Tom Petch - Original Message - From: Rainer Gerhards [EMAIL PROTECTED] To: Chris Lonvick [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 2:48 PM Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) Chris, I fully agree - thanks ;) Rainer -Original Message- From: Chris Lonvick [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 2:39 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [Syslog] #5 - character encoding (was: Consensus?) Hi Rainer, I believe that we are saying the same thing. :) If there is no indicator of encoding or language then a reciever will not know what it is receiving - just like receivers don't know what they are receiving today. They MAY make an assumption that it is something in US-ASCII (but may be disappointed). If there is an indicator of the encoding and language then the receiver will know exactly what it is. Having an indicator should be RECOMMENDED but not REQUIRED for ease of migration. Is that what we're all saying? Thanks, Chris On Wed, 30 Nov 2005, Rainer Gerhards wrote: Chris, Let's use this email as an example. :) There is no indication that I'm using US-ASCII encoding or that I'm writing in English. I think there actually is. If I am right, the SMTP RFCs require mail text to be US-ASCII. Only via MIME and/or escape characters you can include 8-bit data. For example Müller and Möller might create some problems in some mailers (But I guess my Mail system will encode them with =hexval). Dropping messages with octets 127 in the subject is a common spam protection setting... However, you're able to recieve this and read it. Similarly, you could write an email in German and send it to me. I would still be able to recieve it but I'd have a difficult time parsing the meaning. I'm suggesting that same approach for the transmission of the syslog content. If I really wanted you to know what encoding and language I'm using in an email, I would specify a mime header. syslog senders will continue to pump out whatever encoding and language they've been using and recievers will continue to do their best to parse them. If a vendor wants to get very specific about that, then they will have to use an SD-ID to identify the contents of the message. Here I agree with you. What I was saying is that IF the header says it is US-ASCII, only then we should assume it actually is. If there is no enc SD-ID, then we do not know what it is but can assume ... whatever we assume. Let me phrase it that way: If the message contains [enc=us-ascii lang=en] then the receiver can honestly expect it to be US-ASCII. But if it does not contain any enc the receiver does not know exactly and assume anything it finds useful (may be ASCII, may not). Does this clarify? I somehow have the impression we mean the same thing and I simply do not manage to convey what I intend to ;) Rainer Mit Aufrichtigkeit, Chris On Wed, 30 Nov 2005, Rainer Gerhards wrote: Andrew, Hi Rainer, Why don't we look at it from the other direction? We could state that any encoding is acceptable - for ease-of-use/migration with existing syslog implementations. It is RECOMMENDED that UTF-8 be used. When it is used, an SD-ID element will be REQUIRED. e.g. - [enc=utf-8 lang=en] I like that idea too. So, if no SD-ID encoding element is specified, then we must assume US-ASCII and deal with it accordingly?? I think not. If it is not present, we known that we do not know it. If it is US-ASCII, I would expect something like
Re: [Syslog] #7 field order
I was thinking that PRI is also not optional. Tom Petch - Original Message - From: Rainer Gerhards [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 10:06 AM Subject: RE: [Syslog] #7 field order I just got private mail if a missing field is denoted by -. This is the case. Optional fields should be all but VERSION. Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Wednesday, November 30, 2005 9:37 AM To: [EMAIL PROTECTED] Subject: [Syslog] #7 field order WG, there has not been much discussion about the header fields and their order recently. I think this is a sign the issue has been settled. To make sure I got the right understanding of the resulting consensus, I propose that we use the following format: PRIVERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP [SD-ID]s SP MSG That is the format that also proven to be quite useful during my proof-of-concept implementation. If somebody objects, please do that now. Thanks, Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Revised proposed charter
Hi, It would be a good thing to enumerate in the charter the select set of mechanisms to be standardized and included in the charter deliverables by the charter deadlines. That would severely limit any possibility of mission creep, something this group needs to constrain. I am concerned about the lack of commonality in the existing implementations and the difficulty which that presents to reaching consensus. I suggest that it would be useful to agree on the order of message elements and to work from the front of the message to the back, in order, so that if item #5 becomes problematic, at least #1 through #4 can be standardized by the deadline, with #5 remaining implementation-specific, and then the WG can recharter to resolve #5 in a manner compatible with the #1 through #4 standardized message parts. David Harrington [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anton Okmianski (aokmians) Sent: Wednesday, November 23, 2005 12:29 PM To: Chris Lonvick (clonvick); [EMAIL PROTECTED] Subject: RE: [Syslog] Revised proposed charter Chris: This is fine, but does not include all the other specific details we agreed on and as such is not different from what we had before. I think we can focus our efforts better by creating narrower scope. How about limiting backwards compatibility to PRI only. Requiring standardization of better time stamp. Support for FQDN, IPv6. MSGID. Internationalization (UTF-8). Etc... I am afraid that if we leave the charter open-ended as before, we will be debating the charter again 2 years from now. Also, sorry if I missed some earlier discussions on signing messages. Proposed charter mentions source authentication. For TCP mappings (such as BEEP), TLS already provides authentication and encryption. SSH transport would provide similar facilities. Is there an overlap here? Is message signing targeted at just UDP transport? Thanks, Anton. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick (clonvick) Sent: Wednesday, November 23, 2005 12:05 PM To: [EMAIL PROTECTED] Subject: [Syslog] Revised proposed charter Hi All, v2 of proposed charter === Syslog is a de-facto standard for logging system events. However, the protocol component of this event logging system has not been formally documented. While the protocol has been very useful and scalable, it has some known security problems which were documented in RFC 3164. The goal of this working group is to address the security and integrity problems, and to standardize the syslog protocol, transport, and a select set of mechanisms in a manner that considers the ease of migration between and the co-existence of existing versions and the standard. syslog has traditionally been transported over UDP and this WG has already defined RFC 3195 for the reliable transport for the syslog messages. The WG will separate the UDP transport from the protocol so that others may define additional transports in the future. - A document will be produced that describes a standardized syslog protocol. A mechanism will also be defined in this document that will provide a means to convey structured data. - A document will be produced that describes a standardized UDP transport for syslog. - A document will be produced that describes a standardized mechanism to sign syslog messages to provide integrity checking and source authentication. === === Comments please. Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
[Syslog] Forward compatibility
Rainer wrote: I am an IETF freshman. Anyhow, I often read that the IETF was driven by rough consensus and running code. I say was, because my impression is that this is no longer the case. I would prefer it were... While the IETF has increased its theoretical discussions, I think a major part of the problem the IETF faces today is running code. The problem is that implementors insist on **backwards** compatibility with **their** running code. Backwards compatibility is fine when there is a great deal of commonality between existing implementations. As Rainer has pointed out, that just doesn't exist. We need to focus on **forward** compatibility - defining a standard that implementors can move forward toward so there is increased commonality, vendor neutrality, and interoperability. If we keep trying for backwards compatibility to a wide range of incompatible implementations, then we might as well go home now. David Harrington [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] #2, max message size - Need to resolve this
I agree. The syslog-transport-udp-06 draft says this regarding maximum size: This protocol supports transmission of syslog messages up to 65535 octets in size. This limit stems from the maximum supported UDP payload of 65535 octets specified in the RFC 768 [1]. I see no need of restricting it further. For min size it says this: IPv4 syslog receivers MUST be able to receive datagrams with message size up to and including 480 octets. IPv6 syslog receivers MUST be able to receive datagrams with message size up to and including 1180 octets. All syslog receivers SHOULD be able to receive datagrams with messages size of at least 2048 octets. Sect 3.2 also has the rational for all of this - minimum MTU size, recommendation to avoid fragmentation, etc... Anton. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Clemm (alex) Sent: Wednesday, November 30, 2005 9:12 PM To: [EMAIL PROTECTED]; Chris Lonvick (clonvick); [EMAIL PROTECTED] Subject: RE: [Syslog] #2, max message size - Need to resolve this I think there is general agreement to specify minimum msg size, not maximum msg size in syslog-protocol. Concerning the transport, the same should hold true. I could see that there may be cases in which a transport might specify a minimum msg size that is larger than the one in syslog protocol (so, if syslog protocol is used over a certain transport, message size may be larger than what would be mandated by syslog protocol itself). I don't see that you should mandate to define a max message size for the same reasons we wouldn't define it in syslog-protocol itself. Why unnecessarily impose constraints when you don't have to? In other words, just define min sizes that implementations are obliged to support, but don't prevent them from supporting more if they want to. Just my $0.02. --- Alex -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Ross Sent: Wednesday, November 30, 2005 2:41 PM To: Chris Lonvick (clonvick); [EMAIL PROTECTED] Subject: RE: [Syslog] #2, max message size - Need to resolve this My vote is for the way Rainer has worded it now. Specify the minimum msg size in syslog-protocol and define max message size in the transport documents. Cheers Andrew Hi Folks, We need to resolve this one. I've heard from Rainer and a very few others. I'd like to hear from more people on this. Choose one: __ The maximum message length needs to be defined in syslog-protocol. __ The maximum message length should be defined in the transport documents. __ I have a different idea Please VOTE NOW! Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Consensus on Charter?
Hi Darren, I suggest you work with some other implementors of TCP-based syslog to write a TCP transport mapping I-D that can be considered as the starting point for future WG work, if the current work ever gets completed. At a minimum, the document could probably be published as Informational. dbh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Reed Sent: Tuesday, November 29, 2005 1:46 PM To: Rainer Gerhards Cc: [EMAIL PROTECTED] Subject: Re: [Syslog] Consensus on Charter? Are we happy to recharter when these are done to cover TCP ? Darren ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] Forward compatibility
David, I agree with your argument. My point (obviously not properly conveyed) was that I would prefer if *new* efforts would be turned into running code and the lessons learned be applied to the drafts. While implementing, you detect a lot of inconsistencies... Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David B Harrington Sent: Thursday, December 01, 2005 5:40 PM To: [EMAIL PROTECTED] Subject: [Syslog] Forward compatibility Rainer wrote: I am an IETF freshman. Anyhow, I often read that the IETF was driven by rough consensus and running code. I say was, because my impression is that this is no longer the case. I would prefer it were... While the IETF has increased its theoretical discussions, I think a major part of the problem the IETF faces today is running code. The problem is that implementors insist on **backwards** compatibility with **their** running code. Backwards compatibility is fine when there is a great deal of commonality between existing implementations. As Rainer has pointed out, that just doesn't exist. We need to focus on **forward** compatibility - defining a standard that implementors can move forward toward so there is increased commonality, vendor neutrality, and interoperability. If we keep trying for backwards compatibility to a wide range of incompatible implementations, then we might as well go home now. David Harrington [EMAIL PROTECTED] ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] #7 field order
Hi, Can you please ask those who are sending you private messages to make their points on the mailing list, as is appropriate for IETF WG discussions? dbh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Wednesday, November 30, 2005 4:07 AM To: [EMAIL PROTECTED] Subject: RE: [Syslog] #7 field order I just got private mail if a missing field is denoted by -. This is the case. Optional fields should be all but VERSION. Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Wednesday, November 30, 2005 9:37 AM To: [EMAIL PROTECTED] Subject: [Syslog] #7 field order WG, there has not been much discussion about the header fields and their order recently. I think this is a sign the issue has been settled. To make sure I got the right understanding of the resulting consensus, I propose that we use the following format: PRIVERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP [SD-ID]s SP MSG That is the format that also proven to be quite useful during my proof-of-concept implementation. If somebody objects, please do that now. Thanks, Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] #7 field order
David, Can you please ask those who are sending you private messages to make their points on the mailing list, as is appropriate for IETF WG discussions? That's what I typically do. But what if they are not willing to do that and the point is important? Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] #7 field order
Anton, Thanks for the clarification. Your wording is correct. SD-ID will also have - to indicate that it is undefined, which in this case actually means there is none. Rainer -Original Message- From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED] Sent: Thursday, December 01, 2005 7:11 PM To: Rainer Gerhards; Tom Petch; [EMAIL PROTECTED] Subject: RE: [Syslog] #7 field order Rainer, a better way to phrase this is may be that none of the fields are optional (except for maybe SD, depending on how you define the separators). Some fields just have special values which are allowed to designate an undefined value. So, the fields are always there. Anton. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Thursday, December 01, 2005 10:45 AM To: Tom Petch; [EMAIL PROTECTED] Subject: RE: [Syslog] #7 field order Tom, well-spotted. Indeed, PRI is NOT optional. The only one, as far as I am concerned. Rainer -Original Message- From: Tom Petch [mailto:[EMAIL PROTECTED] Sent: Thursday, December 01, 2005 12:35 PM To: Rainer Gerhards; [EMAIL PROTECTED] Subject: Re: [Syslog] #7 field order I was thinking that PRI is also not optional. Tom Petch - Original Message - From: Rainer Gerhards [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 10:06 AM Subject: RE: [Syslog] #7 field order I just got private mail if a missing field is denoted by -. This is the case. Optional fields should be all but VERSION. Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Wednesday, November 30, 2005 9:37 AM To: [EMAIL PROTECTED] Subject: [Syslog] #7 field order WG, there has not been much discussion about the header fields and their order recently. I think this is a sign the issue has been settled. To make sure I got the right understanding of the resulting consensus, I propose that we use the following format: PRIVERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID SP [SD-ID]s SP MSG That is the format that also proven to be quite useful during my proof-of-concept implementation. If somebody objects, please do that now. Thanks, Rainer ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
RE: [Syslog] #2, max message size - Need to resolve this
Hi Rainer, You're the document author - you decide. I'm the WG Chair and my job is to make sure that the work continues. I think that we all would like for the document to be crisp, clear and to the point. Thanks, Chris On Thu, 1 Dec 2005, Rainer Gerhards wrote: Chris, Wouldn't David's text be suitable? I think it is very clear and precise. With it, probably the whole issue hadn't started. I know this WG likes it very brief, but isn't it worth the extra lines? Rainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick Sent: Thursday, December 01, 2005 8:36 PM To: David B Harrington Cc: [EMAIL PROTECTED] Subject: RE: [Syslog] #2, max message size - Need to resolve this Hi David, On Thu, 1 Dec 2005, David B Harrington wrote: Hi Chris, You have framed the question incorrectly. That became evident when people started responding. :) It appears that we have consensus that: - Rainer will place a recommendation of lengths into syslog-protocol so that recievers will have some expectations and, - transport documents will contain a not-to-exceed length requirement. Thanks, Chris This discussion is about the minimum maximum message length, not the maximum message length. This is about at least this big and not about no bigger than. All receivers MUST be able to handle the minimum maximum message size X, and it is RECOMMENDED that all receivers be able to handle messages of size Y, and receivers MAY choose to support sizes larger than Y. Senders can rest assured that any standard-compliant receiver WILL be able to handle messages of size X, so the sender can send a message of that size or less and not worry about it being truncated or dropped (so if it is a critical message, keep the message shorter than X). Senders can rest assured that most, but not all, compliant receivers WILL be able to handle messages of size Y, but there is a chance of the message being truncated or dropped, so if the message is important but you can live with it being dropped, then keep the message shorter than Y, and it will usually work. Senders can try to send messages larger than Y, but many receivers will be unable to handle such a size. Transport mappings may apply different constraints, but regardless of the transport, a compliant implementation MUST support the transport-independent limit X, and it is RECOMMENDED that the transport-independent limit Y be supported for improved interoperability. If desired an implemntation MAY allow larger sizes. Writers of transport mappings should pay attention to these limits. All transport mappings MUST support at least size X. If the transport can support size Y, then the transport mapping contraint should be set to no less than size Y, and for consistency with the transport-independent recommendation, SHOULD RECOMMEND support for size Y (rather than for size Y+1 or Y+2 or Y-7 or ...). If a transport mapping can handle sizes larger than Y, then the transport mapping can support larger messages, and MAY choose to set transport-specific contraints larger than Y. Is this strictly about which transport mapping is used? No, it is not! It establishes some standards that should be followed regardless of the transport used, if possible - all implementations MUST support size X, SHOULD support size Y, and MAY support larger sizes. Dbh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick Sent: Wednesday, November 30, 2005 2:08 PM To: [EMAIL PROTECTED] Subject: [Syslog] #2, max message size - Need to resolve this Hi Folks, We need to resolve this one. I've heard from Rainer and a very few others. I'd like to hear from more people on this. Choose one: __ The maximum message length needs to be defined in syslog-protocol. __ The maximum message length should be defined in the transport documents. __ I have a different idea Please VOTE NOW! Thanks, Chris ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog ___ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
