I went through the mailing list archive, but I did not find one single message wrapping it up. Maybe this here comes close:
http://www.ietf.org/mail-archive/web/syslog/current/msg00772.html Getting the whole thing together requires substantial work. I personally do not think this is useful (given what you have posted). If in doubt, we should probably better ask for advise from our current AD. Rainer > -----Original Message----- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Friday, May 09, 2008 9:38 PM > To: Rainer Gerhards; 'Moehrke, John (GE Healthcare)'; > [EMAIL PROTECTED]; 'Joseph Salowey (jsalowey)'; [email protected] > Subject: RE: [Syslog] I-D > Action:draft-ietf-syslog-transport-tls-12.txt > > Hi, > > Acting as co-chair, I request that everybody please read BCP61, found > in RFC 3365 - "Strong Security Requirements for Internet Engineering > Task Force Standard Protocols". It's short. ;-) > > If the IESG required strong security features for syslog, then the > IESG was probably enforcing the IETF consensus documented in this RFC. > This BCP has not been updated or obsoleted to my knowledge. BUT - the > IESG **may** be working off a newer consensus, so we may need to see > what was said, or get input from our responsible AD. > > I don't think it says the security features must be enabled by > default, or that policy decisions should be included in the protocool > specification. It reports IETF rough consensus that "all IETF > protocols should operate securely". However, RFC 3365 is also clear > that "MUST is for implementers", not users - "it is completely > reasonable for security features to be an option that the end user of > the protocol may choose to disable." > > RFC 3365 does not use the word default, nor the word enabled, and in > my reading of the document, I see nothing that states that strong > security MUST be enabled by default. > > But please continue checking what was said by the IESG when we > rechartered (or whenever it was). > > David Harrington > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > > Sent: Friday, May 09, 2008 12:36 PM > > To: Moehrke, John (GE Healthcare); [EMAIL PROTECTED]; > > Joseph Salowey (jsalowey); [email protected] > > Subject: Re: [Syslog] I-D > > Action:draft-ietf-syslog-transport-tls-12.txt > > > > John, > > > > I need to find it inside the mailing list archive. If I remember, it > > came up during rechartering (2? 3? Years ago). It was along the > lines > > that a secure transport AND secure default for that transport are > > required. This is the primary reason that -syslog-protocol and > > -transport-udp can not advance to RFC before -transport-tls is done. > > > > Rainer > > > > > -----Original Message----- > > > From: Moehrke, John (GE Healthcare) > [mailto:[EMAIL PROTECTED] > > > Sent: Friday, May 09, 2008 6:18 PM > > > To: Rainer Gerhards; [EMAIL PROTECTED]; Joseph Salowey > > (jsalowey); > > > [email protected] > > > Subject: RE: [Syslog] I-D > > Action:draft-ietf-syslog-transport-tls-12.txt > > > > > > > > > Could someone please point me at the mentioned IESG requirement to > > > include policy decisions? This is a very unusual position. > > And as your > > > own assessment shows is something that simply will not scale. > > > > > > For example, there are healthcare systems installed on > > military ships > > > where all network wiring is inside compressed nitrogen casings > with > > > sensors. This is clearly a sensitive environment, but they have > > already > > > managed many of the risks. > > > > > > John > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On > > > Behalf > > > > Of Rainer Gerhards > > > > Sent: Friday, May 09, 2008 3:36 AM > > > > To: [EMAIL PROTECTED]; Joseph Salowey (jsalowey); > > [email protected] > > > > Subject: Re: [Syslog] I-D > > > Action:draft-ietf-syslog-transport-tls-12.txt > > > > > > > > Hi all, > > > > > > > > I agree to Robert, policy decisions need to be separated. > > I CC Pasi > > > > because my comment is directly related to IESG requirements, > which > > > IMHO > > > > cannot be delivered by *any* syslog TLS document without > > compromise > > > > [comments directly related to IESG are somewhat later, I need to > > > level > > > > ground first]. > > _______________________________________________ > > Syslog mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
