> What you are suggesting with your Option 3 is to have a new > part in the > "IANA Considerations" of syslog-sign stating the Facilities > not defined > are open to future use by the consensus process (RFC 2434 > page 6). That > sounds good to me. The current set of Facilities and Severities are > listed by IANA here: > http://www.iana.org/assignments/syslog-parameters
Sounds good to me, too. I have had many discussions off-list (with actual customers ;)) that show this is a good idea. local0...7 is a bit limited nowadays ;) > If we do define new Facilities in syslog-sign, then they will have to > adhere to all of the requirements and specifications of > syslog-sign when > it becomes an RFC. Right now I'm trying to think of how to > "Internationalize" the entire syslog packet rather than just > the MSG part. > It __may__ be that we will want PRI values of <193> to <383> > to have the > same Fac/Sev values as <0> through <192> but a device receiving any of > those PRI's would know that the entire packet (following the > PRI) is in > UTF8. Actually, this is a good idea to maintain some backwards compatibility. But it also has some drawbacks. It does not sound very appealing to me the first place, because... (see below) > That's really just an example of why we may want to > put off that > decision at this time as I'm really waiting for someone from > the IAB to > get back to me on the thought of real Internationalization. > > > Of course you know that these suggestions will require J&J to produce > syslog-sign-13. ;-) Seriously, these are good items to bring up. ... Actually, let me bring back the topic of a separate RFC for the syslog packet format. I would like to see -sign to be moved to the standards track as it is. As you (Chris) said, things can always be revised later ;) Let me provide some points pro a layered architecture: #1 It mustn't be complex, so we can keep it consistent with the spirit of syslog ;) #2 I see some issues right now while acutally implementing the syslog RFC series: I am now implementing RFC 3195. I hope to be able to add -sign soon, eventually with the help of some of Albert's code. When I do so, I run into a small dilemma. OK, I can detect the format used when receiving messages. But when sending, what should I do? I don't know if the receiver (or the relay chain) speaks -sign. This is especially an issue with the relay chain... In theory, I should be able to emit sign-messages and older syslogd's should be able to forward it. I think that was part of -sign's spirit. But I can't do. Well, actually it will become a configuration issue where the admin needs to configure my syslogd and tell it what format it should forward. And, yes, I see this issue at least initially with a layered approach. Now let's say -international once again redefines the packet format. Things become even more complex now. I even see the issue that I won't be able to use -sign on -international messages at all, because -sign demands a specific packet format but -international needs to change this. Now imagine the next modifications, for example when 3195 gets updated or some new cool thing is invented for syslog. Here is the picture that I personally would prefer: Let's finish -sign as it is. It is well done and useful work as it is and I think it should move ahead. Let's put -international on a temporary hold. It is very early in the process and not hurt by some weeks delay. Let's begin to think on a new ID to specify the frame format. That ID should be a) simple b) generic enough to cover the past, present and future (hey, nice marketingish... ;)) Let me post a brief outline of what I think should go into it: - independent of the transport, just the frame format itself. It must, however, be specified to work over a simplex connection as this is the type we have with UDP syslog and probably some other implementations - the enhanced facility,priority Albert suggests - maybe we could change it to something like <facil,prio> allowing for even more choice. This (the comma) would also be a clue that this is actually a new format syslog packet - make everything 8bit, so UTF-8 can be used (-international will become *very* easy) - keep the timestamp, hostname and probably tag as it is in -sign (there is a slight chance that some will opt for a change in the tag) - have some (optional) fields to support fragementation - I am thinking along the line of moving e.g. the reboot session id and the msg sequence number into the format itself - of course, as optional fields - IMPORTANT: have a mandatory field that contains the format of the syslog message. It could be a 1, 2, 3 or a string specifying the RFC or ID... So if there is any change in the format, we'll at least have a clear indication. Obviously, it doesn't solve the issue of not knowing which format the sender is to accept, but at least it provides a clue to the sender that it *indeed is a valid message* but it can't parse that format. Knowing this would for sure do some help in processing dealing with it (right now, the collector needs to guess). In short, the message format would be very much as it is today. In fact, some of these changes would probably be done by -international (at least the 8bit part). But putting this in a separate RFC would allow to let all other protocols refer to it. So even if that format is changed to v2, that doesn't necessarily mean a v1 -sign syslogd could not use it - it would not have all options, but it could perform some work. Again, the important fact is it knows it is dealing with a valid syslog message. I know APIs are not discussed in the IETF, but we should take care of how implemtors can actually implement things. Instead of writing a new message parser/formatter for each new RFC in the series, one could now implement a basic parser that hopefully would stay for quite a while and could be used with all upcoming standards. I am sure this would make implementation much easier (especially if I look at the current config settings /guesswork I need to do in my current parsers...). Of course, that format would still allow us to introduce new features by coockies, which I see as the preferred way of doing things. I am also very positive that we have done enough work to now specify a message format that we can life with for a long time without change (if we follow the cookie approach). So let's assume we had this syslog-message RFC. Then we could do the following. I am repeating myself a little to make it clearer: 1. move on with -sign as it is - no changes, make it become a RFC 2. put -international on hold 3. draft -message once -message has become reasonable mature, at least from its design philosophy 4. eventually in parallel: - go on with -international - change RFC 3195 to adopt -message - change -sign to adopt -message - provide a "transport mapping" to use message over UDP (a new ID) We would end with the following layers Transport Mappings: * revised RFC 3195 * new ID on UDP mapping * eventually a mapping onto 3164, so that exisiting infrastructure can be used to carry new packets (I think this is important) * some others? Basic Format * -message Specific Applications * -sign * -international This is much of what many successful protocols do. It is also the same approach used by BEEP. I also think this will not make syslog complex. It sticks easy. In my point of view, it gets even simpler. From the implementors point of view, it would save me a lot of code that otherwise needs to be written (which also makes it more secure ;)). From the perspective of RFC writers, I think it eases their job because they don't need to re-invent the wheel (packet) every time. So in short, I can't see any bad in this. I would appreciate comments on this and would also appreciate if you, Chris, could include this thought in your talks with that person from the IAB. Of course, I can be horribly wrong, but I have made very well experience with layered approachs and I know it sometimes can even be a life safer. Comments? ;-) Rainer
