Hi, [speaking as co-chair]
Rainer has provided the links to the email discussions of this topic. >From my point of view this was pretty straightforward. We have implementers very involved in this WG, and the implementers expressed a strong interest in TLS. They did not express a strong interest in BEEP. The interest in TLS was so strong, it withstood the challenge of overcoming an IPR disclosure and was preferred over proposals for using SSH or DTLS instead. I think there is a fallacy involved in claiming this is a reinvention of the wheel. BEEP offers certain functionality **in addition** to the functionality provided by using TLS. The WG decided the functionality provided by TLS is important; the additional functionality provided by having a BEEP layer between syslog and TLS is just not as important to most users, and it is seen as unnecessary complexity for most syslog usages. The WG consensus was very clear that TLS alone was preferred over BEEP/TLS. As co-chair, I struggle with whether there is enough interest in BEEP to justify doing 3195bis rather than just moving 3195 to experimental or historic. I see much less WG consensus on the importance of updating 3195. The one segment of the syslog industry that has shown an interest in 3195 is the IHE, an organization whose mission is to promote the adoption of standards for the healthcare industry. According to comments posted to the syslog WG, they have seen little actual deployment of 3195 despite their efforts to promote it. So if we are going to question whether one or the other solution should be dropped, it is pretty clear to me as co-chair which one should go. I have deliberately NOT looked to see if WG consensus is to drop 3195 because the dialogue about whether 3195 is in use is still ongoing, and 3195bis is not yet part of our charter. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -----Original Message----- > From: Sam Hartman [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 08, 2007 9:30 AM > To: Eliot Lear > Cc: [EMAIL PROTECTED] > Subject: [Syslog] Re: Why we're doing TLS > > >>>>> "Eliot" == Eliot Lear <[EMAIL PROTECTED]> writes: > > Eliot> Sam, I got involved recently because both chairs asked me > Eliot> to submit a draft to revise 3195 to reflect the work of > Eliot> -protocol-19. I have done so. And so perhaps you can help > Eliot> me. > > I'll try! > > Eliot> The charter calls for a secure transport. The milestones > Eliot> say TLS (something that could easily be changed without > Eliot> community review, mind you). > > Hmm. I thought that was in the text of the charter, but you're > correct that it is not. It was circulated to the community though > with the charter text. I agree it would not require community review > to change, although it would be revisiting a WG decision. > > > Eliot> A reasonable person could > Eliot> believe that perhaps we might actually *build* on the work > Eliot> that was already done with SYSLOG/BEEP/TLS. As I'm > Eliot> relatively new to the party, I'll accept a pointer to the > Eliot> logic of the choice. There being an IPR claim against the > Eliot> new work, and the fact that multiple interoperable > Eliot> implementations of a proposed standard that could easily go > Eliot> to draft exist, I am hoping that pointer explains why this > Eliot> group is has put aside both interoperability and basic > Eliot> engineering principles of reuse. > > I'd recommend asking the chairs here. It's there job to call > consensus and to the extent that there is consensus on reasons for > decisions (not just the decisions themselves) to be able to explain > that. > > I think that the implementers said they would implement syslog-tls, > but not something 3195-based. But I was not heavily involved in that > discussion other than to make sure it took place. > > > _______________________________________________ > 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
