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 > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
