Rainer: No objections. But I would consider not wasting time on a separate document either.
I think describing relay *operations* may not be necessary at all. Relay can be though of as just a different receiver and, as far as syslog-protocol is concerned, it is just part of the transport to the eventual receiver. The focus of syslog-protocol should be on the message format and semantics of the fields only. We just have to make sure that we provide for enough fields (including structured content) to remove any dependence on using information from the lower layers (like IP packet information). If this done, we don't care about what relays, filters, aggregators, correlators, etc do. At least, if somebody wants to relay the message end-to-end intact, they would be able to do so without confusing the receiver due to modified transport layer data such as source IP/port of relay in the packet. I think we need to state the above assumption that the receiver MUST NOT rely on the information from the transport layer for anything else other than receiving a complete syslog-protocol message. For example, receiver should not assume that the IP address in the IP header of the packet is the IP address of the original sender of the message. It MUST NOT be used as an identifier for message source (hence the need for a standard source IP structured content tag in addition to HOSTNAME field). If that's the case, then you can insert as many relays as you want as far as syslog-protocol is concerned. What do you think about stating this? Anton. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards > Sent: Thursday, April 15, 2004 11:35 AM > To: [EMAIL PROTECTED] > Subject: -protocol issue 15: Describe Relay Mode? > > > Hi WG, > > I would like to once again drag your attention to the > question if we should define syslog relaying in -protocol. > This is tracked as issue 15 at > http://www.syslog.cc/ietf/protocol/issue15.html I think we should describe relay mode in a different document. As I received no other response to my previous question on this topic, I think there is agreement that this should be done in a separate document. Thus, I will specify it as such if there is no further objection (I am about to do the next edit). Rainer
