RE: -protocol issue 15: describe relay operations?
Anton, I think it is may not a bad idea. The only issue is that we will have to produce all three IDs (-protocol, -transport and -relay) all at the same time, right? I think it would be a good idea or it would not provide a complete replacement for RFC 3164. I actually think we do not really need to publish a hyptothetical -relay together with -protocol and -transport-udp. Obviously, this will leave relay operations only vaguely described for some time, but honestly I think it is better we have the base -protocol part straightend out. Implementing -protocol alone will take some time and I do not expect implementors to initially fully support relay operations. Let's look at a real-world scenario: RFC 3195 describes non-relay and relay operations. To the best of my knowledge, there are currently two implementation of RFC 3195: one is SDSC syslog, the other one is my own liblogging (now found in several products). Neither of these two supports relay operations. If it comes to relaying, the act as a receiver and as a sender - but this is different from actual relay operations. Both implementations will go for relaying, but AFIK only at a later stage. liblogging will definitely first include -protocol (once it is more mature and stable) and then look at the relay part. So does it relly hurt if -relay would be e.g. 6 month delayed? I think not. And one more thing to consider: if we really expect that -relay will take quite some time, we must also assume that -relay described in -protocol will take the same time, too (after all, it is the same content). So let's just pick the 6 month as a sample (wild guess). My view on this issue is: if we take relay operations (except for some rough sentences) out of -protocol, we will be able to publish -protocol 6 month in advance and will have -relay ready at the same time when otherwise -protocol would be finished. So what do we have to loose? From the protocol point of view, I think -relay is a very specific issue, so I don't see any good reason that it MUST be described in -protocol itself. However, if all of this is much more work for you or for the group, I don't know if it is worth it. It would make more sense if we indeed end up having to add a lot more stuff for relay operations like ability to envelop the message so it can include original IP, time of reception, etc. If we need that stuff, we need it anyhow. Let's say -relay would be 20 pages (stripped of the boilerplate and such). These 20 pages would either be a document in its own or 20 *additional* pages in -protocol. More so than relay operations, I think my issue with size was related to various implementation guidance that may not be needed or could be counterproductive in some cases. I know it is a fine line. I have pointed a few examples. Sorry for not replying on that - I am currently consolidating the thoughts and also gathering additional feedback. Actually, I am not yet fully prepared to answer on this topic, because I have not fully made my mind up. So it isn't ignorance, but careful consideration what makes me NOT reply now (also applies to Devin's post). Sorry for not telling this straightly. I hope I can reply - at least with an interim post - before Seoul. At least I'll try. Any more comments are obviously appreciated. So far, I am tracking this as issue 13: http://www.syslog.cc/ietf/protocol/issue13.html Rainer
Re: -protocol issue 15: describe relay operations?
I'm guessing that the relay operation that you would like to leave out relates to additional segmenting, and adding missing information, as well as path type information? Leaving all of that out seems reasonable. I think that basic relay operation should be present in -protocol though. By this I'm talking about any constraints on how relays operate, such as the relay MUST (or SHOULD) NOT alter the packet if it is to have any hope of passing -sign messages around. Or someother fundamental point of relay operation (if there is one). I suspect that the bulk of the relaing features you are looking for would only be useful in limited situations anyway. And that basic relay operation will often suffice. But I may be wrong about thit. On Tue, Feb 24, 2004 at 12:01:24PM +0100, Rainer Gerhards wrote: Hi WG, based on the recent comments I received on -protocol becoming too large and in-depth, I wonder if it still makes sense to include relay operations in -protocol? I think this could easily be split into a separate document. If this is not done, I assume that it will take up considerable space. If it should be in -protocol depends on what we actually charter -protocol for. As of my current understanding, -protocol is chartered to not just describe the format of the message but also outline how the protocol itself works. If I am right with this, relay operations MAY be described in -protocol. But I could also envision that -protocol just says there are relays and leaves the details for a different document. Leaving it for a different document would definitely help to finish -protocol soon(er). It would also streamline it, as probably not everyone implementing syslog will necessarily implement relay mode (I assume most will not be interested in this). So my suggestion would be to remove in-depth description of relay mode from -protocol and create a new document once -protocol is FINISHED (and not before). I would volunteer (actually like;)) to write this doc, because I already have a lot of content, which I just would not merge into -protocol for now. Rainer -- Devin Kowatch [EMAIL PROTECTED]
RE: -protocol issue 15: describe relay operations?
Rainer: I think it is may not a bad idea. The only issue is that we will have to produce all three IDs (-protocol, -transport and -relay) all at the same time, right? I think it would be a good idea or it would not provide a complete replacement for RFC 3164. However, if all of this is much more work for you or for the group, I don't know if it is worth it. It would make more sense if we indeed end up having to add a lot more stuff for relay operations like ability to envelop the message so it can include original IP, time of reception, etc. More so than relay operations, I think my issue with size was related to various implementation guidance that may not be needed or could be counterproductive in some cases. I know it is a fine line. I have pointed a few examples. Anton. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rainer Gerhards Sent: Tuesday, February 24, 2004 6:01 AM To: [EMAIL PROTECTED] Subject: -protocol issue 15: describe relay operations? Hi WG, based on the recent comments I received on -protocol becoming too large and in-depth, I wonder if it still makes sense to include relay operations in -protocol? I think this could easily be split into a separate document. If this is not done, I assume that it will take up considerable space. If it should be in -protocol depends on what we actually charter -protocol for. As of my current understanding, -protocol is chartered to not just describe the format of the message but also outline how the protocol itself works. If I am right with this, relay operations MAY be described in -protocol. But I could also envision that -protocol just says there are relays and leaves the details for a different document. Leaving it for a different document would definitely help to finish -protocol soon(er). It would also streamline it, as probably not everyone implementing syslog will necessarily implement relay mode (I assume most will not be interested in this). So my suggestion would be to remove in-depth description of relay mode from -protocol and create a new document once -protocol is FINISHED (and not before). I would volunteer (actually like;)) to write this doc, because I already have a lot of content, which I just would not merge into -protocol for now. Rainer
