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
