> 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
