Hi all, Darren's post clearly shows what is wrong with this WG: we are re-iterating everything. If I get the essence in Darren's message right, what he is proposing is to create a layered architecture for syslog. If you look at my presentation from two years ago (!), you will see that this was the primary driving force behind syslog-protocol. It is available on Chris' site at
http://www.employees.org/~lonvick/attachments/syslog-protocol.pdf The primary difference is that we did the layers starting form RFC 3164 and not from the already-proven-to-be-not-accepted RFC 3195. With syslog-protocol and -transport-udp we initially tried to do just the bare necessities. What Darren recommend is an even broader approach. Please face it: on the WG mailing list, we are pressing for ever and ever change. More and more new things. At least in the last meeting, we are trying to conserve as much as possible (which I personally like). This won't go together. In a previous post, Darren said that the mailing list participants probably do not participate enough in the meetings. And that those in the meetings mostly do not care about the mailing list. I have the feeling that this analysis is correct. Obviously, I am not participating in the meetings for a reason: I simply can not justify traveling around the world for a 30 minute time slot even without a strong business case. I thought that personal participance is not a absolute must in IETF work (though I clearly understand its importance). If that is wrong, we should state that and accept the fact that at least I-D authors MUST participate. That can save a lot of time ;) I begin to feel really concerned about this WG: - the discrepancy about on-list and off-list comments seems to be huge - look at the mailing list archive: we are re-iterating many things ever and ever again - there is very low feedback on the list - we ignore running code and rough consenus existing in practice (syslog/tcp) - the syslog community is not at all interested in the work of this WG (may be a result and not a reason) So please let me ask if we really need a new charter. Or do we need to obsolete the WG? Does it really make sense to put effort into something where only very few participate and even fewer implement? I begin to feel it is more useful if some implementors talk to each other and define what they actually need. That would eventually become running code and maybe later we could turn that into an I-D. The advantage, of course, would be that it actually works and is accepted. On the other hand, the rough consensus and running code on syslog/plain tcp has so far violently been rejected by this WG on many occasions (but thanks to Darren for bringing it up again in his post). So maybe that doesn't make sense, too? Please do not misunderstand me: of course, I am a bit frustrated about the outcome of the last meeting. But that is NOT my driving force. In fact, I like the suggestions from the meeting. But I very strongly fear that this WG has fundamental problems. I personally doubt it makes sense to continue without solving them. One last evidence: if we follow the advise from the last meeting, we could revert back to an earlier version (maybe -02, -03 or so) of syslog-protocol and would have addressed many of the concerns (see http://www.syslog.cc/ietf/protocol.html). Isn't that indication of a serious problem? Rainer > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Darren Reed > Sent: Tuesday, November 15, 2005 11:55 PM > To: Chris Lonvick > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Syslog] Charter revision > > Chris, > > What I'd like to see happen is for 3195 to be broken up into 2 or > more new RFCs, one (or more) which cover the protocol and one which > defines their use over BEEP. > > i.e. One which covers the COOKED profile, one which covers a RAW > profile and one which covers one or both of these over BEEP. > We may also choose to add a BSD profile (which is syslog-protocol > or an enhanced version of 3164.) > > That nails down the protocol. > > Next we move on to defining how the protocol is used. > > So we describe syslog (COOKED/RAW/BSD) over BEEP/ssh/TLS/UDP/TCP. > > I think if we evolve that way there is a much better chance of > aligning ourselves with what people are doing and want to do > without rendering what we've done to the scrap heap completely. > > It may also be worth taking input from those who have developed > or deployed 3195 to understand if there are components of it that > did/didn't work. > > When we get close to getting all of that documentation done, I'd > be for advocating that 3195 be moved to "experimental" status, > rather than obsolete. > > For example, chosing this path gives us a syslog-BSD/tcp that > should be close enough to what people are doing today with this, > bringing together most of these implementations as being RFC > compliant. I expect work will be required on both sides to evolve > it a little to get there, but I think there's considerable advantage > for us and developers if a little work on the part of each party > results in RFC compliant software. > > Sam, do you have any comments on taking this approach with the > syslog protocols by the working group ? > > Cheers, > Darren > > _______________________________________________ > 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
