Hi, I believe it is important to define at least one transport mapping, and to identify this transport mapping as the "required minimum" mapping for compliance to the standard, to ensure that all systems can be expected to support the use of this mapping. This should probably be the simplest transport to implement.
Then we can define additional optional transport mappings, designed to meet specific needs. For example, particular types of systems, as a result of their device type (high end routers, or IDS systems, for instance), might generate a large number of messages compared to most systems; if you exceed X number of messages per minute, you might want to support a streaming protocol where the throughout is known to be better for large amounts of messaging. For systems that are likely to be used over the big-I Internet, where congestion control is critical, it might be important to support SCTP (this extra mapping might also help get it approved by the IESG). But every implementation should support one basic transport mapping. In MIBs, we often define multiple levels of conformance/compliance because different implementations are designed for different purposes. I recommend doing the same for syslog transport support, if the WG is willing to define the various transport mappings. If the WG wants to only define one mappong and leave alternate transports to others to do, then only one required compliance level can be defined. dbh > -----Original Message----- > From: Chris Lonvick [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 04, 2004 9:30 AM > To: Rainer Gerhards > Cc: [EMAIL PROTECTED] > Subject: Re: -protocol: transport mappings > > Hi Folks, > > We need to get this resolved. If you have an opinion on this, please > speak up. If I don't hear anything about this then I will assume that > "0 responses" = "0 interest" and we'll ask Rainer to keep the mapping > as part of syslog-protocol. > > Thanks, > Chris > > On Tue, 3 Feb 2004, Rainer Gerhards wrote: > > > Hi WG, > > > > I had a recent off-list discussion regarding transport > mappings. This > > discussion targeted the quite important point what > transport mappings > > are good for - and wether or not -protocol should contain an UDP > > transport mapping. > > > > My position is that -protocol should NOT contain any > transport mapping > > and that there should be a short RFC outlining how > -protocol is to be > > mapped on UDP transport. Just as it is done in RFC3080 and 3081 for > > BEEP. I would like to do this, because this will make > crystal-clear that > > -protocol is transport ignorant. This is the comment I > received (poster > > requested to remain anonymous): > > > > > I'm a bit doubtful about doing that > > > as it would > > > allow people to do syslog-protocol/tcp, or > > > syslog-protocol/sctp, etc. In > > > one sense, I'd prefer to not open that opportunity as various > > > factions may > > > start doing things their own way which would not promote > > > interoperability. > > > Perhaps one company would choose to implement > > > syslog-protocol/soap while > > > another implements syslog-protocol/http. If we do this, > I'll probably > > > insist that syslog-protocol/udp be a REQUIRED implementation > > > and others > > > are OPTIONAL. > > > > I think this is an very important comment in regard to the overall > > design. I think it is of advantage to facilitate the > creation of other > > transport mappings, as for example is currently being > discussed for SNMP > > inform messages. I agree that it makes it easy to "abuse" > -protocol to > > create non-standard transport mappings. > > > > On the other hand, those doing this would most probably do > it anyhow, > > just not only with their own transport but with their own message > > format, too. I think even if a vendor goes ahead and creates > > syslog-protocol/tcp, this is advantagous over him creating > just a plain > > TCP implementation with a different message format. And as > a reminder, > > this is current state of the art, there ARE many syslog/raw tcp > > implementations in the wild. So the lack of a standard way to do it > > obviously did not stop the implementation. I think it is an > advantage if > > such non-standard implementations at least abide to the same message > > format. > > > > I would deeply appreciate all feedback from the WG on this important > > topic. > > > > Rainer > > > > > > > >
