From mailman-bounces@ietf.org Mon Nov 1 05:31:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12776 for ; Mon, 1 Nov 2004 05:31:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COZiG-0003kD-8p for syslog-archive@ietf.org; Mon, 01 Nov 2004 05:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZ6V-0007cW-KW for syslog-archive@ietf.org; Mon, 01 Nov 2004 05:07:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: syslog-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:02:56 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for syslog-archive@ietf.org: List Password // URL ---- -------- syslog@lists.ietf.org abzuka https://www1.ietf.org/mailman/options/syslog/syslog-archive%40ietf.org From mailman-bounces@willers.employees.org Mon Nov 1 08:11:31 2004 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28985 for ; Mon, 1 Nov 2004 08:11:31 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 641E35D138 for ; Mon, 1 Nov 2004 05:02:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: www.employees.org mailing list memberships reminder From: mailman-owner@willers.employees.org To: syslog-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:00:40 -0800 Precedence: bulk X-BeenThere: mailman@www.employees.org X-Mailman-Version: 2.1.4 List-Id: mailman.www.employees.org X-List-Administrivia: yes Sender: mailman-bounces@willers.employees.org Errors-To: mailman-bounces@willers.employees.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your www.employees.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@www.employees.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@www.employees.org. Thanks! Passwords for syslog-archive@lists.ietf.org: List Password // URL ---- -------- syslog-sec@www.employees.org widuza http://www.employees.org/mailman/options/syslog-sec/syslog-archive%40lists.ietf.org From syslog-sec-bounces@willers.employees.org Tue Nov 2 10:51:49 2004 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03244 for ; Tue, 2 Nov 2004 10:51:48 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 07FB55C7BA; Tue, 2 Nov 2004 07:51:48 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by willers.employees.org (Postfix) with ESMTP id E7CEF5C7B3 for ; Tue, 2 Nov 2004 06:34:32 -0800 (PST) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iA2EYPt17837 for ; Tue, 2 Nov 2004 09:34:25 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Nov 2004 09:34:25 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B401BABE9E@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: syslog-sec@employees.org Subject: RE: [Syslog-sec] RE: Maximum message size Date: Tue, 2 Nov 2004 09:34:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Mailman-Approved-At: Tue, 02 Nov 2004 07:51:46 -0800 X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: syslog-sec.www.employees.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org hi These numbers seem a bit small. I'd rather see the minimum maximum message size to be in the order of 1500 bytes. I also think we should also proscribe truncating rather than discarding. This way people can design their messages with the most critical information first and we will get more intelligent implementations on these resource-constrained message receiving applications. Sharon -----Original Message----- From: syslog-sec-bounces@willers.employees.org [mailto:syslog-sec-bounces@willers.employees.org] On Behalf Of Rainer Gerhards Sent: Thursday, October 14, 2004 12:33 PM To: ietfdbh@comcast.net; syslog-sec@employees.org Subject: RE: [Syslog-sec] RE: Maximum message size David, I see your point. I have no objections in limiting the message size to 2K as long as we keep the door open for senders/receivers supporting larger message sizes. Then the market can decide ... and if there is need for larger sizes, an application can implement it and still claim compliance to the syslog standard. For example, it might be a competitive advantage to support 32K messages, so that a product can be used for the healthcare environment. As such, a vendor might want to implement it. As long as we do not disallow this, the small size is not a problem. And, yes, I agree it will encourage implementors to create short messages. So I am now proposing the following text: #### 5.1 Message Length A receiver MUST be able to accept messages up to and including 480 octets in length. For interoperability reasons, all receiver implementations SHOULD be able to accept messages up to and including 2,048 octets in length. If a receiver receives a message with a length larger than 2,048 octets, or larger than it supports, the receiver MAY discard the message or truncate the payload. #### Rainer > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net] > Sent: Thursday, October 14, 2004 3:21 PM > To: Rainer Gerhards; syslog-sec@employees.org > Subject: RE: [Syslog-sec] RE: Maximum message size > > Hi, > > I have concerns about the requirements for maximum message size, and > would like to propose an alternate approach. > > Most syslog messages currently are less than 1K in size. There is > consensus that 1K is typically acceptable, but it is a bit restrictive > in some circunstances and the size should be increased. I agree with > that consensus. I disagree that the size needs to be increased 64 > times to accommodate normal usage, and I recognize that some valid, > but abnormal, usages do require larger sizes. > > I think it is an unnecessary burden on receiver implementors to be > required to receive 64K messages when 98% of all syslog messages are > likely to be <1K, and 99.9% will be under <2K, just to support those > unusual cases where messages may be as large as 32K or 70K. I dislike > this approach because if all receivers SHOULD support 64k messages, > that will tend to encourage implementors of message generators to make > their messages large and wordy rather than succinct, which could have > a negative impact on the primary use case for syslog. If we set the > required message support to be smaller, most implementors will keep > their messages smaller. > > I suggest that the required maximum size be more on the order of 2k, > 4k, or 8k rather than 64k. This reduced receiver requirement should be > accommpanied by advice that some operational environments, such as > that specified in RFC3881, may require support for larger messages, > and reciever implementors MAY support larger messages or MAY make the > maximum message size a value that is configurable by the administrator > of the system, based on their operational needs. > > This would keep most syslog messages small, yet accommodate special > operational needs such as health care security auditing. > > David Harrington > dbharrington@comcast.net > > > -----Original Message----- > From: syslog-sec-bounces@www.employees.org > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Rainer > Gerhards > Sent: Thursday, October 14, 2004 7:34 AM > To: syslog-sec@employees.org > Subject: [Syslog-sec] RE: Maximum message size > > David and all, > > many thanks for all the good comments. > > I agree that 16 MB for a single message is far more than actually > should be used. Let's look a bit at the history of this: > > Initially, we noticed that the 1024 octet limit for current syslog is > too short. I think there is still general agreement on this. We had a > good discussion about the size issue in September 2003. A link to an > archive is here: > > http://www.syslog.cc/ietf/autoarc/msg00855.html > > The general issue is that 1K is too short for many applications. For > example, Marshall Glen mentions the healthcare needs (RFC3881) for a > larger message. As far as I know, the IHE initiative currently > standardizes on a maximum XML stream size of 32K (which is then > supposed to be transmitted via syslog). I think a message size limit > of 64K would probably be suffcient for a long time to come (and leaves > some headroom for message content increases). > > Besides that, I myself identified a need - in very rare occasions - to > send information larger than 64K. In extreme cases, this information > could be as large as one megabyte. Again, these were cases that might > happen once in a year. All of this, of course, only if an operator > *really* wants to submit that large information. So the initial > approach and suggestion was to introduce a way to build "message > groups". That would have been a way to split "oversize messages" (as > they were called > then) into multiple syslog messages. They key to that concept was that > each single message could be kept within a reasonable limit (it would > have worked even with 1K max message size). It would only have been a > way to transmit very large messages in those very seldom cases that > they would actually be used. > > Some time later, we came to the conclusion that it should be possible > for a single syslog message to be of the largest imaginable size. It > was argued that fragmentation is a transport issue and as such > application-level "fragmentation" (the message groups) would not do > good. We agreed to that. > > Even some time later, we needed to define a maximum message size, just > to limit it somewhere (if I recall correctly, that was a transport > requirement). We picked 16MB just as a number that we thought would > never have be reached and such be sufficient for all imaginable time > to come. As far as I was concerend, that decision was driven by the > fact that in the past there were often limits that nobody expected to > reach - and yet they wer quickly reached. Som 16MB was picked more or > less as "larger than anybody will need anytime in the forseeable > future". We did not even have a big discussion on that limit. > > I think this are the key points on how we reached this limit. Now, > thanks to your call and looking the whole situation, I really think > we've gone overboard. That 16MB limit is something nobody intends to > use. Even a lower - but high limit - is extremely unlikely. I'd expect > to see a 1MB "message" in maybe 0.0001% of the cases - if at all (but > I expect to see e.g. 70KB "message" in maybe 0.001% of the cases). > > Also, I have read your proposal to set a maxium size for the message, > but allow an implementation to go beyond that. Maybe something like > this: > > #### > 5.1 Message Length > > A receiver MUST be able to accept messages up to and including 480 > octets in length. > > A receiver SHOULD be able to accept messages up to and including > 65,535 octets in length. > If a receiver receives a message with a length larger than it > supports, the receiver MAY > discard the message or truncate the payload. > > A receiver MAY accept messages larger than 65,535 octets. #### > > I've dropped the wording that transports MAY support only a smaller > max size - I think UDP was the most critical in this regard and it > obviously handles 64K. So I assume this clause is not really needed if > we go for 64K as the max size. > > With that clause, we would limit the size for all interop cases, but > leave a window open so that the message length could be extended if > there is a real need AND the operator and software vendor wants this. > I assume nobody will implement this burden if there is no market need > to do so. But if it is, it clould at least be implemented in a > standards-compliant way. > > If I look back at the original requirement - provide a way to transmit > very rare oversize messages, I think we can safely implement this the > bounds of the current proposals, even if the size limit does not go > beyond 64K. If somebody needs it, this can be easily done via an > experimental (or vendor-specific) SD-ID. Again, I do not think > somebody will accept this burden without market need. > > In the light of this, I, too, would recommend that we limit the > message size to 64K. I would prefer, however, that we keep the maximum > open as in the suggested wording above. > > Rainer > > > -----Original Message----- > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > Sent: Wednesday, October 13, 2004 5:10 PM > > To: Rainer Gerhards; 'Anton Okmianski'; syslog-sec@employees.org > > Subject: Maximum message size > > > > Hi, > > > > I am concerned that we are in danger of promoting uses of syslog > that > > will defeat its current usefulness as a human-readable log of system > > > activity. > > > > Do network operators really believe the 16,777,216 octet size is a > > needed improvement to syslog, or are we designing this size in > > explicitly for the vendors of applications who want to use syslog as > a > > programmatic interface? I believe Syslog should be designed to meet > > the needs of operators. Most of the discussion ssems to be from > > vendors of syslog receivers or applications. Other protocols such as > > > FTP might be better used for such a specialty use case. > > > > Does allowing messages of 16,777,216 octets to be accumulated within > > > the system log make it harder to use some widely-available minimal > > text editors, like Notepad, to view the system log? Will having huge > > > application-specific messages in the system log make it harder for > an > > operator to locate useful troubleshooting messages within the system > > > log? Can the information in such a huge message fit within an 80x25 > > screen, when an operator is troubleshooting network problems and > needs > > to use a bare-bones terminal attached to the serial port of a device > > > to view the system log? > > > > Syslog was designing to be an operator's tool, and Syslog should be > > designed to meet the needs of operators. Will allowing messages of > > this size negatively impact its usefulness in the primary use case? > > > > What do network **operators** think about the need for messages of > > this size? Have we deliberately asked them their opinion on this by, > > > for example, taking a survey or going to NANOG to ask them? > > > > I don't think we should support such large messages in the system > > logging protocol. > > > > > > David Harrington > > dbharrington@comcast.net > > > > > > > > -----Original Message----- > > From: syslog-sec-bounces@www.employees.org > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Rainer > > Gerhards > > Sent: Wednesday, October 13, 2004 5:17 AM > > To: Anton Okmianski; syslog-sec@employees.org > > Subject: RE: [Syslog-sec] UDP message size issue proposal > > > > Anton, > > > > I agree to your conclusion. > > > > Although I am the one who always voted for larger sizes, the > > discussion has shown that this yields to unnecessary complexity. I > can > > satisfy my needs with a vendor-extension structured data element, > > which I think shows the flexibility of the new drafts. > > > > So I support your move. I would tend to even remove the transport > > version header. If there is need to, we could always include that in > a > > later release (e.g. "v1", which would make it clearly distingshable > > from the current frame format). I see little need to do so, though. > > > > Regarding -protocol, I think we should still keep an upper limit in > > the spec. Even I don't see any reason why a syslog message should go > > > above 16MB. So for -protocol, I propose the following new text: > > > > #### > > 5.1 Message Length > > > > The maximum length of any syslog message is 16,777,216 octets. > Any > > receiver receiving a larger message MUST discard the message. A > > diagnostic message SHOULD be logged in this case. > > > > A receiver MUST be able to accept messages that are 480 octets > (or > > less) in length. A receiver SHOULD be able to accept messages > that > > are 65,535 octets (or less) in length. It is RECOMMENDED that > > receivers be able to accept messages up to the maximum message > > length > > of 16,777,216 octets. > > > > If a receiver receives a message within the maximum length, but > > with > > a length larger than it handles, the receiver MAY discard or > > truncate > > it. > > > > A transport mapping MAY define a maximum length below the one > > specified here. Each transport mapping MUST support a maximum > size > > of 480 octets or more. > > #### > > > > If there is agreement on this, I can post a new version of > -protocol. > > That version will also include some changes made thanks to Andrew > Ross > > comments (sent via private mail). I have finished this version. It > is > > available for immediate posting, but I would like to wait for > > agreement on the size issue (at least if that can be reached > quickly). > > > > Rainer > > > > > -----Original Message----- > > > From: syslog-sec-bounces@www.employees.org > > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of Anton > > > Okmianski > > > Sent: Tuesday, October 12, 2004 11:25 PM > > > To: syslog-sec@employees.org > > > Subject: [Syslog-sec] UDP message size issue proposal > > > > > > Hi! > > > > > > Sorry for a long delay on this issue - I was on a 2 week vacation. > > I > > > have spoken with a number of TCP/UDP/IP experts regarding the > sizing > > > > > issue. I am ready to propose the following changes: > > > > > > 1. Syslog-protocol will state that the max message will be defined > > by > > > the transport layer. > > > > > > 2. Syslog-transport-udp will support messages up to maximum UDP > > > datagram size of 64K. UDP is a very bad choice for large message > > > transmissions, so it does not make sense for us to stretch it by > > > adding our own fragmentation without other transmission control > > > features such as found in TCP. > > > > > > 3. Syslog-transport-udp will rely on IP fragmentation and we will > > get > > > rid of "proprietary" fragmentation which was designed to handle > > > messages over 64K and deal with various > > > non-compliant network hosts. > > > > > > 4. Syslog-transport-udp will recommend sending messages within the > > > > boundaries of prevalent MTU size on a given network to be safe. It > > > > will recommend Ethernet's 1500 bytes less headers and will draw > > reader > > > attention to the minimum MTU size hosts on the network are > required > > to > > > support for > > > IPv6 (576 bytes) and IPv6 (1280 bytes). > > > > > > 5. Path MTU discovery may not work robustly and some TCP/IP stacks > > may > > > not support UDP packets of full 64K size and truncate them. We > will > > > > > mention this and bite this bullet. > > > We should not restrict the protocol due to incompliant > > implementations > > > because it is a moving target and penalizes compliant > > implementations > > > with extra overhead. The above size recommendation would partially > > > > deal with this, but leave the > > > final choice up to the administrator. > > > > > > 6. We will get rid of most syslog transport headers for UDP as > they > > > will no longer be needed. The only thing that will be left is the > > > > transport protocol version prefixed to every syslog message. > Should > > > > > we even bother with that? > > > > > > This is a major change to the syslog-transport-udp. I'd like to > get > > > > > positive feedback before I proceed with this update. > > > The best part is that if we all agree on the above, the next draft > > > > will be 1/3 of the size -- easier read for you. :) > > > > > > Thanks, > > > Anton. > > > > > > > > > _______________________________________________ > > > Syslog-sec mailing list > > > Syslog-sec@www.employees.org > > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > _______________________________________________ > > Syslog-sec mailing list > > Syslog-sec@www.employees.org > > http://www.employees.org/mailman/listinfo/syslog-sec > > > > > > > _______________________________________________ > Syslog-sec mailing list > Syslog-sec@www.employees.org > http://www.employees.org/mailman/listinfo/syslog-sec > > > _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec From syslog-sec-bounces@willers.employees.org Fri Nov 12 15:45:55 2004 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17666 for ; Fri, 12 Nov 2004 15:45:55 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id CF1175C731; Fri, 12 Nov 2004 12:45:55 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by willers.employees.org (Postfix) with ESMTP id BCC135C79D for ; Fri, 12 Nov 2004 12:07:37 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08305; Fri, 12 Nov 2004 15:07:34 -0500 (EST) Message-Id: <200411122007.PAA08305@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 12 Nov 2004 15:07:34 -0500 X-Mailman-Approved-At: Fri, 12 Nov 2004 12:45:54 -0800 Cc: syslog-sec@employees.org Subject: [Syslog-sec] I-D ACTION:draft-ietf-syslog-transport-udp-03.txt X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: syslog-sec.www.employees.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : Transmission of syslog messages over UDP Author(s) : A. Okmianski Filename : draft-ietf-syslog-transport-udp-03.txt Pages : 10 Date : 2004-11-12 This document describes the transport for syslog messages over UDP/IPv4 or UDP/IPv6. Syslog protocol layered architecture provided for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementors are required to support this transport protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-transport-udp-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-transport-udp-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-12134810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-transport-udp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-transport-udp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-12134810.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec --NextPart-- From syslog-sec-bounces@willers.employees.org Tue Nov 16 20:10:35 2004 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19086 for ; Tue, 16 Nov 2004 20:10:35 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 5CDE95C7C9; Tue, 16 Nov 2004 17:10:32 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by willers.employees.org (Postfix) with ESMTP id 8821E5C72D for ; Tue, 16 Nov 2004 13:13:51 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14742; Tue, 16 Nov 2004 16:13:48 -0500 (EST) Message-Id: <200411162113.QAA14742@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 16 Nov 2004 16:13:48 -0500 X-Mailman-Approved-At: Tue, 16 Nov 2004 17:10:31 -0800 Cc: syslog-sec@employees.org Subject: [Syslog-sec] I-D ACTION:draft-ietf-syslog-protocol-08.txt X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: syslog-sec.www.employees.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : The syslog Protocol Author(s) : R. Gerhards Filename : draft-ietf-syslog-protocol-08.txt Pages : 40 Date : 2004-11-16 This document describes the syslog protocol which is used to convey event notification messages. This protocol utilizes a layered architecture, which enables use of any number of transport protocols for transmission of syslog messages. It also provides a message format which allows vendor-specific extensions to be provided in a structured way. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-protocol-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-protocol-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-16113122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-protocol-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-protocol-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-16113122.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec --NextPart-- From syslog-sec-bounces@willers.employees.org Wed Nov 24 10:52:32 2004 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05311 for ; Wed, 24 Nov 2004 10:52:32 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id C7F2B5C7B6; Wed, 24 Nov 2004 07:52:32 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from ietf.org (odin.ietf.org [132.151.1.176]) by willers.employees.org (Postfix) with ESMTP id A13D05C7BA for ; Tue, 23 Nov 2004 12:08:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17309; Tue, 23 Nov 2004 15:08:13 -0500 (EST) Message-Id: <200411232008.PAA17309@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 23 Nov 2004 15:08:13 -0500 X-Mailman-Approved-At: Wed, 24 Nov 2004 07:52:30 -0800 Cc: syslog-sec@employees.org Subject: [Syslog-sec] I-D ACTION:draft-ietf-syslog-sign-15.txt X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Security Issues in Network Event Logging Working Group of the IETF. Title : The syslog Protocol and Signed syslog Messages Author(s) : J. Kelsey, J. Callas Filename : draft-ietf-syslog-sign-15.txt Pages : 31 Date : 2004-11-23 This document describes a mechanism to add origin authentication, message integrity, replay-resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-syslog-sign-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-syslog-sign-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-23142216.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-syslog-sign-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-syslog-sign-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-23142216.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec --NextPart-- From syslog-sec-bounces@willers.employees.org Tue Nov 30 13:16:59 2004 Received: from willers.employees.org (willers.employees.org [192.83.249.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16214 for ; Tue, 30 Nov 2004 13:16:58 -0500 (EST) Received: from willers.employees.org (localhost.employees.org [127.0.0.1]) by willers.employees.org (Postfix) with ESMTP id 2783E5C75C; Tue, 30 Nov 2004 10:16:56 -0800 (PST) X-Original-To: syslog-sec@employees.org Delivered-To: syslog-sec@employees.org Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by willers.employees.org (Postfix) with ESMTP id 4D48B5C75C for ; Tue, 30 Nov 2004 10:15:44 -0800 (PST) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 30 Nov 2004 10:15:58 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAUIFgA5020076 for ; Tue, 30 Nov 2004 10:15:43 -0800 (PST) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA17354 for ; Tue, 30 Nov 2004 10:15:42 -0800 (PST) Date: Tue, 30 Nov 2004 10:15:42 -0800 (PST) From: Chris Lonvick To: syslog-sec@employees.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 30 Nov 2004 10:16:54 -0800 Subject: [Syslog-sec] Progress X-BeenThere: syslog-sec@www.employees.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Mailing list for the syslog Working Group in the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: syslog-sec-bounces@willers.employees.org Errors-To: syslog-sec-bounces@willers.employees.org Hi Folks, We're getting very near to completion of the two base IDs. :) Anton has updated the syslog transport ID and it may be found here: http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-udp-03.txt Rainer has also updated the syslog protocol ID and it may be found here: http://www.ietf.org/internet-drafts/draft-ietf-syslog-protocol-08.txt Please take a few moments to review them. Many thanks, Chris _______________________________________________ Syslog-sec mailing list Syslog-sec@www.employees.org http://www.employees.org/mailman/listinfo/syslog-sec