Rainer and all: I think there are two issues here:
1. Should UDP transport be required? 2. Should UDP transport be included in -protocol? I think they are interdependent. If the consensus of the WG that it must be required, then I agree it is easiest to put it into -protocol. But, I have a sense that requiring UDP would not be a good thing I see a few issues with requiring it: 1. It has a danger of making UDP a defacto-implementation and we know UDP is not always ideal. It can discourage other transport implementations. I think somebody mentioned the fate of SNMP in this regard. 2. I think requiring UDP implementation reduces the areas in which syslog message format RFC could be utilized. I can see many different areas. For example, if RFC came without UDP baggage, we, within Cisco, could potentially standardize on this format for products which write directly to log file (no syslog servers) should be compatible with the format. This would be a great thing for us to be able to have a consistent format regardless of whether or not syslog transport is used because it is inevitable that some products will use syslog and other will write straight to file. Another use case I have is writing log messages into Windows Event Log. I would really like if that format be the same as on other platforms which use syslog. It would have been easier for us to establish this requirement for products within Cisco if we could just refer to syslog message format RFC and it did not come with a baggage of having to implement a syslog UDP transport, which may not be applicable. So, I am open on whether or not UDP binding is included in -protocol or outside. But I would really prefer if it was not required. Thanks, Anton. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > Sent: Thursday, February 05, 2004 11:18 AM > To: Anton Okmianski; Andrew Ross; Chris Lonvick; Harrington, > David; Marshall Rose > Cc: [EMAIL PROTECTED] > Subject: RE: -protocol: transport mappings > > > > From: Anton Okmianski [mailto:[EMAIL PROTECTED] > > > > 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 David has a valid point here (besides that he has > obviously brought "a little" of his SNMP experience in...). I > think the value of REQUIRING that there must be a simple > mapping (I think UDP is this for > syslog) is that we can ensure that at least all > implementations can interoperate with each other. If we do > not have a REQUIRED transport, we may end up with two syslog > implementations that can not talk to each other, because one > talks UDP while the other talks TCP. Neither of them talks > any other protocol. > > I see much value in avoiding this situation. I think it is > even worth requiring a transport that one may think to be too > simplistic. We can leave it to the administrator to disable > this transport, so this should not be an issue. But a least > common denominator should be available if there is no other > way to get it going (after all, getting things going somehow > is better than loosing the game at all...). > > The only issue I see is with devices - or better said "pure > senders" - whom's vendor will not put in the extra effort to > implement two transports. I doubt, however, that a vendor who > puts in a more sophisticated transport like RFC3195 has an > issue with providing an UDP transport, too. > > Anyhow, to avoid issues in this regard, we may want to relax > the REQUIRED transport mapping for "sole senders" (that is > non-receivers, not e.g. a relay). I am myself not sure yet if > that is a good idea, but after all, this is a discussion list ;) > > > > > 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 am in strong favour of a separate RFC, even though it is a > pretty short one (I doubt it will be short in respect to > security considerations ;)). But it will keep things cleanly > separated. However, I see that once we really require a > transport (UDP), that it may only complicate things. So I am > not feeling as strong about a seperate RFC as I did some days > ago. I am still in favour of it, but things like "this > complicates the RFC process" may outweigh this concern. > > I have CC'd mtr - I don't know if he has time and is willing > to comment on this issue, but I would deeply appreciate it > because he obviously has experience with this by doing > RFC3080 and 3081 in the same manner. > > > I think a separate transport RFC will promote multiple transports, > > which I personally thing is a good thing. > > me too. I think it pays to open this possibility... > > > > > 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. > > I think this is a re-iteration of the first argument. At > least my comment from there applies here, too. ;) > > Rainer > >
