Anton, I am on the road with bad connectivity, so it took some time to get to this..
> From a quick glance, it seems the max length is not specified although > somewhere there is a reference to section 4 for it. I don't have access to the published draft right now, but at least it was supposed to say "max of ~16MB". I'll check ASAP and eventually re-adjust. It should also say "keep it below 499 bytes". > > Definitions & Architecture sections talks about senders and receivers, > which is good, but still has the picture with various relay/collector > stuff. Are you planning on removing it? Well, if there is strong objection, I can remove that. But I think it is better to keep it in, because it defines names for several roles - this may make it easier in the future to use the same name for the same thing. > > Again, I have a problem with a term "machine can generate". I think > we need to refer to applications or processes. Syslog is not a > protocol for "machine-to-machine" (host-to-host) communication only. > Like we said before, receiver and sender can be on the same machine. > So, we have applications or processes interacting, not "machines". I > think we need to mention that multiple senders and multiple receivers > can co-exist on the same host. A particular transport protocol can > impose restrictions on receivers. In my sec, I say that receiver MUST > support listening on a standard syslog port and MAY listen on another > port. I basically agree - I've not re-worded this so far, because I am focussing on the other things, first. I thought, however, that the description of the relay with the original sender process already covered at least some of this idea... But definitely not enough of it ;) > Why do we default to IPv6 unknown IP? It is longer. I can change this, but I think/hope some time IPv6 will look more natural - no other reasoning for this. > I also don't > understand the value of distinguishing the IPv4 unknown IP and IPv6 > address. It is still unknown. It also creates ambiguity, what is the > stack supports both. I found this possibility while describing the scenarios. I can remove it, if that is concensus. > "The TAG is used to denote the process sending the message." Should > this be a MUST? I pass this on to the list... It sounds good, but doesn't we need to create a TAG value repository in this case? > > "The static ID SHOULD always remain the same for a given sender > process." I think you mean "application" here. The process is a > specific instance of an application which is identified with dynamic > part, right? If you referred to process name, then it is the same for > different process instances. You are right, "application" is the right term here. > > "The full-dyn-id SHOULD change with each new instance of the sending > process." SHOULD or MUST? Strongly opt for SHOULD - else you need to make sure that the OS does not accidently assing you the same PID as a previous process. And, yes, I agree this is extremely unlikely, but it is a possibility... > > "Traditionally, the full-dyn-id should reflect the process ID of the > new instance." I think the word "traditionally" implies we are trying > to follow some established standard, but there is no such thing. > "Traditionally... Should..." does not sound right. Agree, "traditionally" needs to be removed. SHOULD must be upper case. The rest - I think - is right. > > I know you wanted to keep some resemblance of the old ad-hoc syslog > format, but two separate fields for TAG would make life much easier > then having to find the last [ and only if there is ] at the end. If > we make two fields, they would be APP-NAME (or PROCESS-NAME) and > PROCESS-ID. This is much more intuitive then describing it as static > vs. dynamic. And this is what people are after in the end. We could > allow for say "-" for unknown process ID. But I think requiring > APP-NAME is a must. What do you think? That sounds good - I actually did not have this good idea. If there is no objection, I'll change it to this in the next draft. Rainer
