Hi!
I assume this is the forum to provide the feedback on this draft.
Title : Syslog-international Protocol
Author(s) : R. Gerhards
Filename: draft-ietf-syslog-international-00.txt
Pages : 13
Date: 2003-8-1
-
From: Anton Okmianski [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 12, 2003 11:30 AM
To: [EMAIL PROTECTED]
Cc: Nathan Sowatskey; David Bainbridge
Subject: RE: syslog-int
Hi!
I assume this is the forum to provide the feedback on this draft.
Title : Syslog-international
Rainer:
You are digging deep :), but I agree with your sentiment. Buckle up
for a long message. :)
It is not intuitive to me that syslog-sign takes on the job of
specifying the format for key syslog parameters such as timestamp,
host and tag. I understand this was done out of necessarily, but
I'd like to insert my 2 cents if I may.
I agree that multi-part messages are good to have in the protocol.
For two reasons:
- messages greater than 1024 octets
- better presentation of multi-line messages
The lines breaks fall into the latter category. I think one would
achieve better
Rainer:
I think...
1. Fragmented messages should be supported over any transport
including legacy UDP syslog. If you lose some fragments over
unreliable transport, it is expected. A way to determine that this
happened would nice to have. I think even your original proposal
addresses this with
Just to clarify...
I don't think that host/process/time is the best unique identifier for
messages. The example that I gave also included per-process sequence
number (count which resets to 1 on restarts). But even this format is
not as good as one with reboot id because time can be moved
Rainer:
Sorry if I did not follow earlier discussion and misunderstand
something obvious. But here is my feedback.
I like the key=value approach. A lot! This would be hugely welcome in
syslog and this is a great undertaking! To begin with, we could plug
things like severity and facility because,
Rainer has proposed adding metadata as a field in the protocol
(formerly called cookies)
I count this as a vote for the term metadata and will
assume this issue is solved when nobody objects it ;)
Meta-data is ok, although I would have preferred referring to these as
just tags since this
Below some thoughts...
Use strict XML such as:
cookie msgno=123 encoding=USASCII /
Use loose rules so the information can be easily converted to
XML (if one wishes) such as:
cookie msgno=123 encoding=USASCII
Define the format and delimiters with little regard to any
conversion to
Rainer:
Good draft! I have a laundry list of suggestions/questions below. Feel
free to respond to them in different emails at your convenience. The
issues are in more or less section order.
1. First, I have to say I don't understand the backward compatibility
aspects. RFC 3164 compliant
Rainer:
Sorry, but I am still not getting backwards compatibility business.
Please help me understand it.
Clients which fire messages in RFC.new format are always going to be
compatible with RFC 3164 servers regardless of what we put into RFC.new.
This is because RFC 3164 allows anything. The
Rainer:
Oct 11 22:14:15 myhost2 su: Message with line break\nbefore end
ah, ok, so solaris does this processing, obviously when writing
to the file. That would mean that we would need to apply escaping
to the free form part of the text, too. Not a bad idea...
Especially as I think the \x
Rainer:
I hope I have annoyed you too much with my non-stop comments,
but I think we are making good progress!
I meant I hope I have NOT annoyed you, obviously. :)
Sorry.
Anton.
Rainer:
I made a comment earlier about how we should specify character set in
terms of Unicode and UTF-8. You may want to reference RFC 2277, which
provides guidance on IETF Policy on Character Sets and Languages.
Basically it says three things:
- must support UTF-8 character set/encoding
-
On issue #7 - enterprise ID:
I am relatively neutral to this idea. But I am trying to understand how
it will be used. What are the anticipated use cases for it?
If we want to use it to differentiate messages from a specific vendor
because it may provide some additional formatting, then one could
I agree with general consensus that there must be at least one mapping.
I guess UDP is easiest. But I would prefer that compliance with this
transport is not required as far as -protocol. We all know UDP may not
be an ideal transport, so a TCP-based syslog (provided it adheres to a
standard)
Chris:
Sounds reasonable. Let's get the other stuff completed first.
Anton.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick
Sent: Tuesday, February 10, 2004 3:55 PM
To: Anton Okmianski
Cc: [EMAIL PROTECTED]
Subject: RE
Rainer:
I would like to turn to issue 8, that is structured data
element placement. I have put together the (few) most
important thoughts here:
http://www.syslog.cc/ietf/protocol/issue8.html
Anton proposed that we
a) allow elements only in their own, well-defined field
b) merge that
: Wednesday, February 11, 2004 11:57 AM
To: [EMAIL PROTECTED]; Anton Okmianski
Subject: syslog message size and fragmentation
Hi WG,
I had an off-list discussion with Anton that lead to the
discovery of a new issue in -protocol, that of message
fragmentation. -protocol specifies a message size
Rainer:
I have to admit I am not 100% sure what the UDP spec says: If
a UDP packet becomes fragmented (due to MTU), is it
guaranteed that the packet will be re-assembled by the
receivers IP stack before it is passed up to the app layer?
What if a fragment is missing? Will the whole packet be
Rainer:
#1 is more a spec-stunt than a real solution ;)
In 4.4, RFC 3339 says
###
o Use another host in the same local time zone as a gateway to the
Internet. This host MUST correct unqualified local
times that are
transmitted to other hosts.
###
Definitely a
Rainer:
It is a tough one. You almost convinced me. But you talk about server
implementation's side only. What about client's side?
If I write a Java client and 0x00 is a prohibited character, do you
think I will have to scan each string passed to me to make sure it does
not include 0x00? It
:24 AM
To: Harrington, David; Anton Okmianski; [EMAIL PROTECTED]
Subject: RE: -international: trailer
David,
thanks for your wake-up call...
I believe we should move to UTF-8 to allow operators who
UTF-8 is actually a MUST in syslog-protocol.
I have to admit that I did not fully
: [ + string + ]);
Output...
Length: 4
String: [AB C]
Anton.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Harrington, David
Sent: Friday, February 06, 2004 12:49 PM
To: Rainer Gerhards; Anton Okmianski; [EMAIL PROTECTED]
Subject: RE
PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards
Sent: Thursday, February 05, 2004 11:18 AM
To: Anton Okmianski; Andrew Ross; Chris Lonvick; Harrington,
David; Marshall Rose
Cc: [EMAIL PROTECTED]
Subject: RE: -protocol: transport mappings
From: Anton Okmianski [mailto:[EMAIL
David:
I am really struggling with that restriction not to
standardize syslog
storage in IETF. It diminishes the value of the syslog protocol as
people can't write a standard syslog parser.
I'm not sure I understand why you feel this. Assuming you are
parsing what was sent on the wire,
between the first relay and subsequent relay for
this to work, right? Maybe if information is already in the structured
content, then relay should not update it and the originator will
recommended no to use that parameter.
What do you think?
Anton.
-Original Message-
From: Anton
: Thursday, February 19, 2004 6:53 AM
To: Anton Okmianski; [EMAIL PROTECTED]
Subject: RE: syslog-transport-udp ID 00 - source port requirement
Hi Anton,
thanks for the fine ID :)
I am commenting on the source port issue. In RFC 3164, port
514/UDP is recommended as source port. This recommendation
Hi!
I will reply to various emails in one.
Who makes the assertion that you can trust my timestamp? An
application? As Devin points out, an application has no way
to determine whether a timestsamp is valid, and thus cannot
be trusted to make a valid assertion on its own.
Application can
Rainer:
In the light of this sum-up, I propose the following compromise:
- we will continue to use the rfc 3339 timestamp in its
unmodified way
- we will ignore that RFC 3339 calls for timesync (because
we can't ensure it)
- there will be NO header field indicating the reliability
Rainer:
I think it is may not a bad idea. The only issue is that we will have
to produce all three IDs (-protocol, -transport and -relay) all at the
same time, right? I think it would be a good idea or it would not
provide a complete replacement for RFC 3164.
However, if all of this is much
ALbert:
I'm in the process of reviewing the current dradt, after I
have been very busy for some time.
I hope to send a full review in about 1 or 2 weeks (I will
not be there in Soul and will delay my comment untul your are
back) But due to private communication with Rainer, I will
post my
Rainer:
Are you going to specify a message size limit in -protocol?
I think we do need some limit. For fragmentation in -protocol I need
to know how many bytes to dedicate to the fragment offset and
potentially message length.
I suggest we limit it to 4GB in size (32 bit size) or 16MB (24 bit
]
Cc: Anton Okmianski
Subject: RE: Issue 14: allow unqualified hostname
Anton all,
in IPv6, we have the unspecified address, which I think is
exactly what we should use in the case an device does
actually know nothing about itself (last case in Anton's
messsage below) it is 0:0:0:0:0:0:0
Rainer all:
Let me comment on something...
- esay human interaction - not just reading but also (telnet)
crafting messages
(I couldn't envision troubleshooting SMTP configs without
the ability to
telnet SMTP commands)
This is analogy is not quite kosher IMO. SMTP uses
Hi!
I am pondering what recommendations/requirements we should set for
maximum datagram sizes in syslog UDP transport protocol. Messages of
certain size would have to be fragmented. I have done some research
and want to propose that we set the following strict limits on
datagram sizes:
- IPv4
this is reasonable, so I agree. Probably -protocol
should recommend that the message is below 500 bytes - an
efficiency hint...
Rainer
PS: I am out of office during most of this month with limited
connectivity.
- Ursprüngliche Nachricht -
Von: Anton Okmianski[EMAIL PROTECTED
37 matches
Mail list logo
