Rainer, I had a similar reaction when I first looked at RFC3195 and BEEP etc, with a view to implementing it. However, I don't think it is as complex as it appears at first glance. It also seems to me that any of the "overhead" is actually stuff that you would be doomed to reinvent in any alternative (just like UDP was originally chosen for being "simple" but it turns out TCP was needed).
Maybe I've missed something, but try this: print out RFC3195, throw away all the pages referring to the COOKED profile and "additional provisioning", and see how many pages you are left with. Then refer to the example exchanges. It looks to me like a sockets programmer could figure out how to talk to this inside of an day or two, even without any BEEP library. I'd be surprised if the resulting code was very long, too. How does this (the RAW profile of RFC3195) differ from the "simple reliable" you describe below, except that it's upwardly compatible with the remainder of 3195? If something like RAW++ is desired (more than 1024 characters, etc), that should be easy to define as either a new profile or an upgrade to RAW (i.e. the underlying RFC3164), and still keep the implementation requirements very light. Cheers, Frank > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Rainer Gerhards > Sent: 16 December 2002 11:35 > To: Christopher Lonvick; [EMAIL PROTECTED] > Subject: Any chance for a Simple Reliable Syslog Protocol? > > > Hi all, > > Based on discussions I had outside of this WG, I would like to ask for > the possibility to specify a kind of "simple reliable syslog protocol". > RFC3195 is definitely well done work. However, I see some serious issues > with it: > > - (Un)availibility of BEEP > As it looks, BEEP has limited availability to say the least. I have > posted a question on the BEEPwg mailing list last week asking for > library implementations. I got no response at all (except for Marshal > Rose who requested that new libraries should be registered at > beepcore.org). So as it looks, BEEP is limited to BEEPcore (which has > some serious issues right now) and Roadrunner (which is hard to use > without redisigning your whole application [and also hard to use for > closed-source projects]). > > - Complexity of BEEP > I wonder if we will ever see an implementation of BEEP (and thus > RFC3195) in routers and especially low-end devices like printers and > small vendor's routers. > > - Need to redesign your application > If I got it correctly, there is strong need to redisign an application > in order to use it with BEEP. Honestly, we do not want to redisign our > full product line just to add support for one additional protocol. > > I have followed the relevant lists and so far have the impression that > most implementors stay away from RFC3195 for one or more of the above > reasons. > > So in (current) reality, we are back to the usage of "traditional" > (maybe not even RFC3164) syslog if we would like to receive messages > from a heterogeneous set of sources. The good point is that we have a > widely accepted protocol and it performs relatively good most of the > time. But there are weaknesses. Most stem from UDP usage. > > I hope that it is possible to specify a protocol that fills the gap > between RFC3164 and RFC3195. A *simple* syslog reliable protocol, that > provides: > > - reliable transport via TCP > - a much larger allowed message size than 1024 characters > - support for non-western characters > - some more meta data (like the full-blown timestamp, but this might go > into the content area and as such might be outside the charter of this > WG. I am still mentioning it so at least some header changes can be > considered) > - maybe hooks for optional encryption and authenticy - but this might go > too far > - most importantly is easy to implement and does rely on right now > readily available libraries, which unfortunately means sockets, only... > > I wonder if this WG would be willing to step forward into that > direction. I am sure such a protocol would not the least be as elegant > and advanced as RFC3195, but I think this is it's key advantage: being > simple, we would be able to get more implementors to actually implement > it. So we wouldn't achieve the 100% that RFC3195 brings, but maybe the > important 50% of it. Well, and that looks much more than we currently > have... > > Keep in mind: my key point is that improovement is needed *now* (which > means quickly), so I am looking for a solution for the next few years. > Maybe this would even be an interim-solution until BEEP becomes actually > available... > > Any feedback is highly appreciated, > Rainer Gerhards > Adiscon > > >
