-Original Message-
From: David Harrington [mailto:[EMAIL PROTECTED]
Sent: Friday, January 12, 2007 10:31 AM
To: [EMAIL PROTECTED]
Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
Hi,
[speaking as co-chair]
Finally, we are getting discussion of the
I second Jeurgen's analysis. I'd like to understand a technical
argument (if there is any) for requiring that extra bit of logic and
creating a potential for errors.
Anton.
-Original Message-
From: Juergen Schoenwaelder [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 13, 2006
David:
Part of it is that we reviewed a lot of the syslog-protocol before the
last WGLC, and it did not change much since. I think we just added the
pri header, right?
So, I have not given this version a close review because I reviewed much
of the same content for 2 years up to the last WGLC.
Here are two things we need to resolve soon.
1) whether draft-ietf-syslog-transport-tls should use
byte-counting, special character, or both, including which
special character. We want to finalize this WG decision by August 18.
My vote is for byte-counting and no magic characters.
I thought we were targeting the TLS transport to the new
syslog-protocol, not the current informational RFC 3164. There are some
considerations in the charter for partial syslog-protocol compatibility
with RFC 3164. But I don't think we have called for the new transport to
necessarily work with
David:
Please clarify...
Are you suggesting we drop syslog-protocol, which actually defines message
format, and just do a generic secure transport for events? Something that just
does framing, app-level ack and had generic payload?
And then we continue to live without syslog standard,
John:
The standards you listed define not just payload, but also the
whole messaging. WSDM uses SOAP over HTTP. CIM-CX / WBEM - non-SOAP
XML over HTTP.
I am not sure what we can add to help the above other than to say
use TLS.
Or do you want syslog WG to provide an alternative messaging
Rainer:
A few thoughts on 3195bis. Generally, I like the idea of app-layer ACKs.
1. I think the format would need to be changed a bit more than you suggested.
If you do XML, you should do it all the way -- not mix it with special
delimiters. Structured data, for example, should be encoded
-Original Message-
From: David Harrington [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 21, 2006 2:44 PM
To: Chris Lonvick (clonvick); 'Rainer Gerhards'
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] IESG secure transport requirement can
be quicklysolved...
Hi,
[speaking
I was just talking to Rainer about similar concern.
I think first of all we need a basic mapping to TCP or more generally define
syslog payload (framing) format for connection-oriented protocols. This should
cover sending multiple messages over the same connection, obviously. The same
AM
To: Anton Okmianski (aokmians); Tom Petch; [EMAIL PROTECTED]
Subject: RE: [Syslog] stream
transportwasdraft-ietf-syslog-transport-tls-01.txt
Anton,
-Original Message-
From: Anton Okmianski (aokmians) [mailto:[EMAIL PROTECTED]
Sent: Friday, June 16, 2006 5:25 PM
To: Tom
I agree that Darren is overreacting in words, but maybe not in substance. I
think that a co-chair generally plays some role within his own company, and
can/should steer it away from behavior disruptive to the work of the standards
body that this co-chair is overseeing. I would expect that from
:[EMAIL PROTECTED]
Sent: Thursday, June 08, 2006 8:39 AM
To: Rainer Gerhards
Cc: Anton Okmianski (aokmians); [EMAIL PROTECTED]
Subject: RE: [Syslog] Draft-ietf-syslog-transport-tls-01.txt
On Thu, 2006-06-08 at 09:38 +0200, Rainer Gerhards wrote:
Hi all,
I agree with Anton on all
Royalty-free does not generally mean free! It means you don't charge
per-end-user, per-server fee. But it does not mean there is not fee. Plus,
license terms suggest other reasonable, non-discriminations terms and refer
to reciprocal license needed to implement standards. Notice plural.
I
My 2 cents... Do the byte counting. Look at the headers of pretty much any
successful protocol (TCP, IP, UDP, etc) - they all specify length of payload.
Special character sequence is really a hack IMO!
Just to be clear, there was never any intention to allow multiple messages per
UDP
I second Tom's opinion.
I think we should not preclude the use of transport that supports encryption,
but I don't think it is as high a priority as integrity and authentication of
origin. Certainly, there should be an option of not incurring encryption
overhead when all you need is integrity
I think the suggestion from me and Tom (if I interpret his email correctly) is
to state that messages can be truncated at the end at an arbitrary point. We
also make a note that this may result in invalid UTF character encoding, or a
change in UTF character.
I don't think it even warrants a
I think having a lightweight secure transport option without requiring PKI is
good. If one were to use PKI, no doubt TLS beats SSH as an established
standard. But using PKI is not trivial and should not be a requirement IMO.
Based my experience with SSL/TLS on an unrelated product, private
Banzsi:
I agree truncation does not solve the issue - that's why I don't want to
over-design it.
Splitting is an option I'd leave to application-layer running above syslog. It
is not precluded. Just a matter of another RFC with extra sd-elements.
If we do fragmentation in syslog
Rainer and all:
I'd like to propose a slight terminology change for syslog protocol for
structured data. I think there is confusion even in this group about current
terminology. For example, we (me included) keep referring to structured data
element, when we mean structured data parameter.
-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards
Sent: Monday, January 09, 2006 4:49 PM
To: Anton Okmianski (aokmians)
Cc: [EMAIL PROTECTED]
Subject: RE: [Syslog] Sec 6.1: Truncation
Rainer:
I agree - this is better than a convoluted rule.
I
3:21 AM
To: Anton Okmianski (aokmians)
Subject: RE: [Syslog] Sec 6.1: Truncation
Anton, Darren,
I agree that the truncation rule is probably not really
useful, even confusing. I think it is hard to predict for any
potential message if the more interesting content is in
STRUCTURED-DATA
Rainer and all:
I started reading draft #16. Since we are revisiting everything... I am not
very comfortable with the current truncation rules.
Receivers SHOULD follow this order of preference when it comes to truncation:
1) No truncation
2) Truncation by dropping SD-ELEMENTs
3) If 2) not
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
Specifying the encoding makes sense to me. This way we can state that only
certain encoding support is required, but not preclude other options.
We are still ok with always having UTF-8 in SD values, right?
We need this for foreign usernames. We have discussed this before.
Thanks,
Anton.
Darren:
If you really want to get back to basics, I'd not accept any
maximum message size that was bigger than 490 bytes
(576-14-64-8) as this is the largest frame size that IPv4 is
*required* to reassemble. Either you remove the maximum
message size from syslog-protocol or drop it to
I vote for a different idea... As in latest syslog-protocol, define only the
minimum message size the receivers is required to accept. I vote for defining
it in both. Syslog-protocol defines the least common agreed upon denominator.
Transport defines the minimum that is appropriate for the
Which system is this source from?
On Solaris, if you send \r\n characters, you will see ^M\n in the log.
Anton.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Darren Reed
Sent: Sunday, November 27, 2005 3:23 PM
To: Rainer Gerhards
Cc: [EMAIL
Darren:
WG,
PRIVERSION TIMESTAMP HOSTNAME APP-NAME PROCID [SD-ID]s MSG
I would put the SD-IDs after the message.
The SD-IDs and detailed bits of meaning to the MSG and
without the MSG, are irrelevant. The exception being a
language marker.
I would prefer SD-ID where it is in
Glenn:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Glenn
Mansfield Keeni
Sent: Monday, November 07, 2005 2:21 AM
To: [EMAIL PROTECTED]
Subject: [Syslog] Re: I-D
ACTION:draft-ietf-syslog-transport-udp-05.txt
Folks,
A few minor
30 matches
Mail list logo
