I agree with general consensus that there must be at least one mapping. I guess UDP is easiest. But I would prefer that compliance with this transport is not required as far as -protocol. We all know UDP may not be an ideal transport, so a TCP-based syslog (provided it adheres to a standard) should not be required to provide a UDP binding.
I think the cleanest approach is to put the transport into a separate RFC and publish the UDP mapping concurrently with -protocol. However, considering that the whole transport description for UDP is just "use port 514", I am not sure if the WG wants to go with the overhead of extra RFC instead of just adding a section to -protocol. Personally, I don't mind a one page RFC. And I think most security issues needs to be moved to transport layer. I think a separate transport RFC will promote multiple transports, which I personally thing is a good thing. If we make UDP part of -protocol, we should make it only conditionally required. Kinda like multiple levels of compliance in MIB that was suggested. I think it has to be stated that for UDP transport the following conventions MUST be used. But providing the UDP transport itself is not a MUST. Anton. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Ross > Sent: Wednesday, February 04, 2004 7:28 PM > To: 'Chris Lonvick'; 'Rainer Gerhards' > Cc: [EMAIL PROTECTED] > Subject: RE: -protocol: transport mappings > > > > I agree that having a separate RFC for mapping syslog into > various transports would be good. Then we could address > Syslog over UDP, TCP, BEEP, SNMP, yada yada. > > Maybe also make a mention in protocol that it is transport > independent and refer them to the transport RFC name. > > Cheers > > Andrew > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Lonvick > Sent: Thursday, 5 February 2004 3:30 a.m. > 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 > > > > > > > > > >
