Healthcare doesn't demand beep, actually beep has been a problem for us as well. We choose 3195 because there was no viable alternative. We have paid the price of no implementations. I think that the current path of syslog is ok with us. The MTU is sensitive, and I like your proposal to deal with that. We eagerly await and encourage the current syslog-protocol work.
John > -----Original Message----- > From: David Harrington [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 08, 2007 11:31 AM > To: 'Sam Hartman'; 'Eliot Lear' > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] Re: Why we're doing TLS > > Hi, > > [speaking as a contributor] > > I learned a lesson about standards while working on SNMPv3. The cost > of added features required by only a segment of the market should be > borne only by that segment of the market. > > Just because one segment of the market wants the functionality of an > extra feature, that is not a strong argument for forcing everybody to > support the extra feature. A standard is better when the core > functionailty wanted by everybody is made mandatory, and add-on > features are optional, to be implemented/deployed only by those who > want those features. > > As we discussed message sizes in syslog, members of the IHE community > pushed for very large messages. The WG questioned whether the usage > proposed by IHE was within the applicability scope of syslog, which is > primarily designed for logging small messages to alert operators of > system anomalies. The WG chose to recommend the use of small > messsages, but to allow for implementations to choose to support large > messages, to meet this demand from one segment of the syslog > community. > > I have not argued against doing 3195bis because that same segment of > the syslog community, members of the IHE, has stated there is no > viable alternative to 3195, and they would rather use a standard > protocol than invent a new one. They like the reliability provided by > BEEP. > > In my opinion, the rest of the community should not be forced to > implement BEEP to get TLS just because there is a special interest > group that wants BEEP. My impression as a contributor is that the WG > is willing to allow the option of BEEP as a supplement to TLS, > although some implementers have said they would not support it in > their products until there was customer demand for it. > > 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 > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
