Hi All,
Apologies for the delay - I've still got a very heavy travel schedule for
the rest of this week and most of next.
I agree that the WG consensus is to produce syslog-transport-tls.
Alex is re-drafting syslog-sign to ride atop syslog-protocol. This will
remove the dependencies of 3164 and 3195 from syslog-sign.
I would like to see the work on 3195bis proceed to complete that effort
and allow it to be used as another transport for syslog-protocol. I
believe that it has beneficial characteristics that are not covered in
syslog-transport-tls nor syslog-transport-udp.
Thanks,
Chris
On Thu, 8 Feb 2007, David Harrington wrote:
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
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
