Subject: RE: [Syslog] Revised proposed charter

From: "David B Harrington" <[email-masked]>
Date: Thu, 1 Dec 2005 11:03:57 -0500

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-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Anton 
> Okmianski (aokmians)
> Sent: Wednesday, November 23, 2005 12:29 PM
> To: Chris Lonvick (clonvick); [email-masked]
> 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-masked] 
> > [mailto:[email-masked]] On Behalf Of Chris 
> > Lonvick (clonvick)
> > Sent: Wednesday, November 23, 2005 12:05 PM
> > To: [email-masked]
> > 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/syslog
> > 
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 1 Dec 2005 11:14:52 -0500

Hi,

I will observe that the syslog MIB has been declared "dead" in the
ID-tracker, and it has expired in the I-D repository. Is this
deliberate, and if so, why? No explanation is given in the ID-tracker.

dbh. 

> [mailto:[email-masked]] On Behalf Of Glenn 
> Mansfield Keeni
> Sent: Thursday, November 24, 2005 5:33 AM
> To: [email-masked]
> Subject: Re: [Syslog] Revised proposed charter
> 
> Chris,
>      You seem to have dropped the last deliverable which is 
> in good shape
> 
> >     - A MIB definition for syslog will be produced.
> 
> I would strongly recommend that we include it. It is an 
> important aspect
> of the protocol. Some effort has gone into it. And it is the least
> controversial [there are no issues of backward compatibility]. And
it
> is very close to completion.
> 
> Glenn
> 
> Chris Lonvick wrote:
> > Hi All,
> > 
> 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.
> > 
> mechanism
> > to sign syslog messages to provide integrity checking and source
> > authentication.
> > 
> > 
> > === ===
> > 
> > Comments please.
> > 
> > Thanks,
> > Chris
> >