Hello Chris,

your proposal sounds good.  I don't disagree with any of your items
(which means, I agree with alll of them:-)   

Concerning the particular questions that you raise:  

"Should we continue to have the MSGID in the header, or should that
become 
an SD-ID element?"  

I believe it will be preferrable to have it in the header, not require
an SD-ID for that.  

"Could we add a language tag as an element in an 
SD-ID to indicate the language of the MSG?"

I believe SD-ID would be the right place to put this one.  A
corresponding SDE could be defined at a later point in time.  

"We need a version.  Should that be in the header (after <PRI>), or as
an 
element in an SD-ID?"

I believe it is preferrable to have it in the header, not require an
SD-ID for that.

--- Alex



-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick
(clonvick)
Sent: Monday, November 21, 2005 11:12 AM
To: [EMAIL PROTECTED]
Subject: [Syslog] New direction and proposed charter

Hi Folks,

I'd like for us to come to closure on some things.  I'm going to be a
bit direct on these questions so we can focus quicker.  We really need
for people to send in responses to see who's listening and involved.



>From the meeting, it sounds like we will get many more implementations 
>if
we continue to use <PRI>... at the start of syslog messages.  This will
allow current receivers to continue to receive messages and put them in
the right bins.  Does anyone disagree with this?


The WG has agreed to use the timestamp Rainer has in the current
syslog-protocol.


Using the FQDN and numeric notations for IPv4 and IPv6 addresses has
been 
agreed to.


Putting in the Structured Data still seems like a great evolutionary
step 
for syslog.  I'd like to see that go into the new syslog-protocol.  Does

anyone disagree with this?


Should we continue to have the MSGID in the header, or should that
become 
an SD-ID element?


We've had slow-downs in our prior discussions about truncation and
message 
length.  To complete this work without revisiting those discussions, and

in the spirit of backwards compliance with traditional syslog, I propose

that we accept the length as Rainer has proposed in syslog-protocol, and

disallow any device to truncate the messages.  At some future time, 
someone can augment the syslog-protocol standard and define a mechanism 
and signalling that will allow truncation.  Does anyone disagree with 
this?


Encoding has been discussed and we have agreed upon US-ASCII and UTF-8
in 
appropriate places.  Could we add a language tag as an element in an 
SD-ID to indicate the language of the MSG?


We need a version.  Should that be in the header (after <PRI>), or as an

element in an SD-ID?


One possibility would be to assemble a syslog message as:

<PRI>TIMESTAMP FQDN VERSION MSGID [SD-ID]s MSG



If we can agree to this then I suspect that we can have a working
document 
within Rainer's timeframe.  I'll propose the following charter to keep
us 
focused.

-------- 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 of the existing syslog mechanism while not breaking
backwards compatibility.  The most obvious problems that need to be
addressed in the syslog protocol are the timestamp, which has not
formally included a means to indicate the year, and the identification
of the source which has been a hostname without a qualified domain
name.  Additionally, a version, some type of message indicator, and a 
means to convey structured data will be included in the protocol.

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 standard will be produced that formally documents the syslog
protocol.  A mechanism will also be defined in this specification
that will provide a means to convey structured data.

- A standard will be produced that documents the UDP transport for
syslog.

- A standard will be produced that documents a mechanism to sign
syslog messages to provide integrity checking and source
authentication.

- A MIB definition for syslog will be produced.

-------------------------------------------


PLEASE review this and respond.

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

Reply via email to